I made a suggestion on how to create a SharePoint project structure in my "SharePoint Development" presentation at Microsoft Copenhagen back in January, but there is no documentation on it in the PowerPoint presentation.
In my experience, I find that keeping the number of WSP packages down to a minimum is the easiest thing to managed. Therefore I put all my SharePoint artifacts in one project. Some large SharePoint solutions may require more than one WSP package, but generally not many. I also separate the business logic from the SharePoint project, so it will not be GUI dependent. I use this structure as a general template whenever I create a new Visual Studio solution.
This project is not specific per solution, but can be used as a library across multiple solutions. This project do not contain any business or SharePoint logic, only clean .NET code. I usually create a lot of.NET Extensions in this project.
This project is for generally SharePoint related extensions and is still generic across multiple solutions. A lot of .NET SharePoint Extensions is added to this project.
MyCompany.BusinessModel (or ObjectModel)
This project will contain all my business logic and data objects. The project will not contain any UI logic.
MyCompany.MyProjectName (SharePoint Project)
This is the SharePoint artifact project from where I will build my WSP package by use of WSPBuilder. All the SharePoint webparts, features and so on will be created here. It is usually set to deploy to Global Assembly Cache. However if company policy requires the code to be deploy with Code Access Security (CAS), I will create an additional SharePoint project, so I have one project for the GAC and one for the WebApplications bin folder.
The project for Units tests.
I do not say that this is the best structure, but I find it as a good template to start from, specially that I can reuse the Framework projects from solution to solution.