We were thinking about organizing our BIG project this way:
\\trunk [CompanyName] [Product1] [Project1] CompanyName.Product1.Project1.csproj
With respect to file names - I prefer that my project file name match the output assembly name because it makes it much easier to know what produces what. Doing a directory listing is much faster than searching the csproj files in a tree for the one that produces the assembly I care about.
I don't get worked up about solution files because they don't influence our build environment so I end up making my own to have the exact scope I want (and the specific per-solution items, like test metadata, that I want).
With respect to folder structure - I don't worry too much if the folders leading down the project files match the namespaces. I want my code to sit on disk in a way that makes the most sense for the project. Sometimes this means the test code and product code are in sibling directories - sometimes it means they are much further apart. Sometimes there is a namespace that is contributed to by multiple teams (not advocating that design, just a reality) - but those teams want to life in their own folders for whatever reason.
Don't forget the importance of version control branching strategies in your overall project design. The Company and Product boundaries may be branches and therefore would not necessarily need to represented as directories on disk.
Don't let this be a source of analysis paralysis though. Make a reasonable choice. Use version control. You can always change later if you are wrong.