Well, in the recent past we had one project per database where all mapped classes redsided, but we had zero logic anemic modes - no methods, only mapped classes. This is mostly because in this areas (2 projects: data warehouse and financial trading) data has no moethod but either is not manipulated outside a loader (Data warehouse) or run through a service architecture where results are queued for writing (no logic again).
Before that I used my own and it had the ability to merge multi project mapping schemas - which is extremely important for modular applications where you may not want everything to be in one module, database wise.
are suppose to define all your database under a single project
Now that would be STUPID. See, if I work on 4 software solutions, al ahaving databases, and the only common ground is I work on thjem, then having one database project is stupid - it breaks source control, continous integration and makes it hard to exchange info with other programmers working on ONE of the solutions. Whatever you do, the "project" (as in: project management, not in Visual studio project) is ahard boundary (as in: TFS Project, directory hierarchy) and should not overlap with other projects.
or define database per application under a single project
AT least you isolate applications, but what with databases shared by applications (as in: I have one project as in Project maangement consisting of one solution but it has 5 applications (exe files) - not everything is a simple trivial website. My current main proejct has a server application, a client application, 2 websites and a dozen or so external tools so far and we are jsut starting with PowerShell integration ;)