When structuring a visual studio solution I tend to structure it so that various components are in different project (As I would assume most people do) I tend to have a bunch of User defined exceptions.
The Question is should these exceptions be in a separate project to the (for example) Model classes?
I tend to put them in a sub-namespace of the model, and organise them in a directory within the Model project. but should they be in a separate project all together?
Depends on how they're used I guess. If the exception is confined to a single project, put it there. If several projects use it, put it in a separate project.
It depends on how you imagine them being used and how you deploy your application. As a rule of thumb - never create more packages/assemblies than needed.
There's one strong case for putting Exceptions and Interface classes in their own assembly and that's when they're supposed to be shared among clients that not necesarily need to "full" package, one common scenario is when using remoting another is when building plugin architechtures.
I wouldn't bother as long as the message strings are configurable (properties file/xml). Having a generic top level interface would definitely help though, if the exceptions were to span across projects.