I enjoy discussions about abstract models, partly because that's my primary area of expertise, and partly because there aren't enough of them!
In any case, I agree that a good conceptual model can lead to a shared, unified language across the whole enterprise - IT and non-IT both included, and that this is one of the highlights of a good model. Sometimes it really does come down to the apparently - but not actually - simple task of naming things correctly. Clear, precise names mean clear, precise concepts in dicussion, which promotes in clear, precise requirements and clear, precise solutions.
On the other hand, I'm not so certain about the model itself being something that non-IT people need be exposed to directly. There's a sort of common misconception that data modeling is something anyone can do on intuition alone. And, sure, anyone *can* look at a business, its process and entities, and come up with some kind of model. But it takes actual expertise and experience to come up with a correct model.
What do I mean by correct? I mean one with is, in fact, a representation of the subset of reality being modeled, and which also (and therefore) contains no internal contradictions. Reality, after all, entails no contradictions. Therefore if the model does, then the model is not a representation of reality.
Sure, sometimes this is trivial. But sometimes it is not, and being able to see when it is not is a skill, and it is this skill which requires expertise and experience. One needs to be able to look "through" the model and see all of the logical consequences of what has been wrought. I have found, in the past, that exposing business people to the model directly will result in them making suggestions regarding changes directly to the model - "let's put this column over here instead", or "this seems complicated, can't we just do x?", or "Why is inventory separate from asset? They're the same". (no, they're not), or "Why is customer separate from account? They're the same too" (no, they're not either). This is not a situation you want to be in. What the business people should be telling you about are the functional requirements, the business processes, and so on. They are absolutely not qualified to build, or critique, a data model as such.