I'm doing some research in this space at the moment, and I believe the key words (at least from what I relate to) in your post are "consistent enterprise data model".
Given your experience, I have no doubt that you know the difficulty in achieving this within large organisations. And it seems that you feel this doesn't disuade anyone from at least 'encouraging' a large enterprise to adopt some semblance of 'consistency' in their dialog. I feel the same. It may also be true that, in the production of a data-warehouse, that it is your client's mandate to the data-warehouse developer....'please bring us closer to consistency'.
With the work that I'm doing with ORM, I've come to a few conclusions, which may be similar to ones that you already harbour:
1. 100% consistency across the entire Enterprise may not be achievable, but there is definitely a hierarchy of Facts (and models) which is not only achievable...but is manifest by 'nature/logic' and by standards that are universally adopted (more on this below).
2. To the extent that 1) (above) is true, perhaps it isn't so much ORM that provides the leverage, as either the tool/s with which you work to generate the data-warehouse and/or to develop your ORM models by.
To explain...the research I am doing focuses on those conceptual models that can be covered off in 1) (above) first, and attributes them to the highest level of the hierarchy (i.e. the 'Enterprise'). These include
a. Things that are true in all worlds (and we can be a little bit lenient here and say 'almost always true')
e.g. 'Human blood is of color, 'red''. (just as an example).
b. Things that are universally accepted. (e.g. 'In the language English, blood contains a substance called 'Haemoglobin')
I'd stamp this type of data (when manifest as records in the data-warehouse), with the EnterpriseId to indicate that they are true across the entire enterprise.
(NB Not teaching anyone how to suck eggs here...merely that "that's one ORM model in its own right"....)
But if part of the Enterprise does 'blood research', and they've decided that 'haemoglobin' is too general a term, and have come up with 2 descriptions (say 'FactorX' and 'FactorY')...then I'd stamp that data with the Unique Identifier for the 'blood research' group (...another ORM model...).
So in essence, I'm investigating ORM models that map the 'Enterprise' along with (as an inclusion of) the UoD that you are modeling.
That's where my research is at, and that's where we are pushing development. What I personally feel is the benefit of this approach is that the ORM models can be done at any level/branch of the Enterprise, and still be consistent. i.e. They are consistent with the 'language' spoken by the practitioners at each level/branch of the Enterprise.
Then, as the Enterprise matures...and the 'blood research' group decides that they were wrong after all (for example), lower level/branch 'Facts' may be either escalated 'up' the hierarchy (to more general widespread use), or stay static, or be dropped (as e.g. 'defunct'). Which again, kinda matches the way that language/terminology/facts grows/morphs/evolves within the large Enterprise. i.e. the data-warehouse/database wouldn't be lying, just reflecting a reality.
I'd be interested to hear your interpretation on this and whether you share similar sentiments.
Ultimately, on the front line, you'll know exactly what your client 'wants'. It would be interesting to hear a perspective on that. Do clients want a data-warehouse/EnterpriseModel that 'changes the Enterprise', or one that reflects and (may rapidly) 'change with the Enterprise'?