I've seen some teams that start breaking into multiple projects from the beginning and others build behemoth single projects. The large project teams say that one massive project is easier to maintain than multiple smaller projects.
In general, how many files is too many?
The answer as George suggested it depends...but you may have large project with many areas which are new feature with asp.net mvc 2.0 . The time when you do want to break it another project is when you are trying to reuse that in another project. Since you do not want something coupled that it needs quite a few changes to work.
So, you need to analyze and understand the reusability of your projects.Ideally you would not want to have one big project with everything...you can divide into libraries..helpers..Models..etc..But again depends on how and what are you implementing..and sometimes a one large project also works.
If all your projects are in one solution, there's not really much of a difference (until you get beyond 10 or so projects). If you only plan on having one app, keep it in a single project but separate by folders if you feel that is easier.
We typically separate our project by tiers ... i.e. a web tier project, model/business logic tier, and data access or OR/M tier. It makes it easier for us to manage and conceptually think about the various apps. It also helps prevent us from mixing together concerns (i.e. you probably wouldn't want your model accessing the System.Mvc namespace, but if everything is in one project it's easier for a developer to slip such 'features' in).
There is probably no right or wrong answer here, but from experience, some teams know that certain components logically belong in a separate project, therefor they break it down initially.
Some teams might find that because a project is unmaintainable in it's current form, decide to break it down logically into more manageable parts.
As developers, we should always be breaking down problems into more manageable and consumable bits of work. The concept applies to solutions/projects that grow to a size that is just not favorable.
Short and simple answer. If it becomes to big and messy, break it down.
We don't worry so much about 'files in project', rather we subdivide by 'projects contain logically related function'. Our base libraries are divided by functional area (UI, data access, etc), then the app components by function - reporting, contract maintenance/info, various odd & sundry table maintenance things, deal maintenance/info, rights maintenance/info, etc. (some of the terminology is domain-specific)
Given our translated-from-client/server app is fairly large, we decided that logically related separation would provide a simpler maintenance scheme.