Heres my musings.
Put all LLB code in an LLBLGEN directory so that anyone regenerating can checkout the whole thing, regenerate and then check back-in. Make sure you include the .lgp file in this.
Experiment with your source control system to see if some new files are not automatically checked in.
Switch off the .lgp backup feature and use your source control for versioning it.
Have agreed procedures for locking the LLB code when someone is regenerating and not use shared checkouts.
If you are all working off the same test database have a set time of day or week for making big changes to the database (really this means deleting things).
Any use you can make of daily builds or unit testing will help pickup problems sooner.
Make sure that everyone gets trained on LLB before they start on the project. The learning curve isn't that big, but I have had a lot of resitance to it on the grounds that developers are 'used to other ways of coding'. Its easy for one developer to ignore the 'spirit' of an LLB project and write their own DB code.
Decide in advance what features you will allow. Can developers create stored procs, views etc? If they can, it can quickly undermine the point of using of LLB.
Decide how you are going to organise the architecture. Are you mainly using manager classes, partial classes or inheritance? When should each be used. Standardise or you will get duplicate code.
If you are using VS2005 make use of code snippets and distribure these to developers.
Create examples of code in a 'how do I' document that can be cut&paste.
One thing I would argue not to do is have one person responsible for the db and LLB code up to the business layer. Its tempting to do this, but personally I think its a bad idea.
