I think Peter overemphasizes VS problems with large projects. I've worked with pretty large solutions and projects without other problems than slight slowdowns.
I'll describe how I organize my projects.
First of all you need a Shell project which is the backbone of the application and offers services to the different modules of your application.
Next you need a data layer project which encapsulates interaction with the database. Here you can choose a strongly-typed datasets, a generated DAL, etc. You can break this project in different modules around business areas if needed.
The third project should hold all the business logic of the application. Data manipulation is done here. You can break this project in different modules around business areas if needed.
Then you need another project for the reports and finally you have a UI project (which may be split) which contains user controls and the forms that the application uses.
For large projects, I usually have tables in the database to dynamically build the shell's UI. For example, the database could contain a Admin.Forms table which the shell reads to build a tree of forms on the left side of the main window. When a form in the tree is double clicked, the shell creates a new instance of the form with the name of the type (a field of the table) and adds the form to a tab control for an MDI look easily implemented.
I hope this helps,