It totally depends on the scale at which your team is doing/planning these customizations. On naming there are no rules as such. However, as a guideline try to have a non conflicting package naming convention for all your customizations and extensions. That should be easy by just adding your company name in the package names.
For extensions where you have to deploy the newly built artifacts, the standard is to prefix the jar/war or any other deployed artifact name with XX. So, if you are deploying employee.jar name the deployment profile as XXemployee.jar . This will make sure that any future upgrades or patching wont wipe your own deployed artifacts.
One thing that is not documented in the Rel 6 version is to avoid using the package name oracle.apps.cust as it is internally reserved by MDS team. This is fixed in later versions of documentation.
Regarding your question on number of applications etc. It would be good to maintain one application per product family. If your team is distributed over geographic areas then use version controlling to coordinate the modification on the same set of files. Whether it's a run time customization or a design time customization, remember that a single MDS document is maintained per layer. As an example if you make a runtime customization on HrViewEmployee.jsff at Global layer and then if you wish to do some design time customizations using JDeveloper on the same page fragment at the Global layer then MDS will only maintain the version which is saved later. Which further means that if more then one developer will attempt to customize the same artifact without the knowledge of prior customizations made by other developers then there are fair chances to wipe out previous customizations. So, to avoid/minimize it, the best would be to let the entire team always work on a single version controlled copy of customization artifacts.
Hope this helps
Its surprising that oracle has not set any recommendation or best practice for the fusion apps customization and extension, while we know its quite unstable and on the top of that no standards been defined and put on the mercy of the implementers .......great opening the cans of worms.