I agree with many of your comments, especially on naming conventions. Naming conventions are totally arbitrary and are meant to allow the team to work together with minimal communication issues. I am consultant and each project we get the team to agree to naming standards before we start. They are necessary and what works for the team is acceptable.

And now the big BUT :-), after over 40 years of development I have learned you do not name data elements based on their attributes ... never. I am referring to your DR, DT notations. How much effort is required to change the application if a column is changed from a nullable to not nullable or the other way around? Where are all the column references? How about the references outside RAD like reporting and BI applications and their meta-data? I am not saying you can't manage this, but why introduce the risk?

Overall, good job and good ideas. Many low cost UML tools implement this philosophy and provide for standard name generation, key structures, DOM, etc. and they have the ability to support multiple DBMSes and application environments (i.e. .net vs java, IIS vs others, etc).