Accelerated Data Models are like summary indexes. That is, they will contain bits and pieces from events (the fields from the events that the data model includes) but they do not contain the the original event, nor pointers to them. You are correct, unlike Splunk's normal late-binding schema, data models are a little more rigid, and as such can offer speed when reporting.
Typically, when attempting to drill down from the accelerated data to actual events, the root search for the data model is used and combined with the other information from the accelerated fields, and the time range to get to the original event. However, this is running a new search to pull the event data (and possibly multiple events) based on the summary data, not "this is the event that relates to the accelerated data". I hope that makes sense.
It's important to remember that accelerated data models are summaries, and as such a single accelerated entry in the data model should point to more than one event. If you make the data model too specific, you end up with a bloated data model that will take up a lot of space (the data model included with the Palo Alto app is an example of this, as it includes very specific fields like an ID with each event, you end up with a very large accelerated store).
For information on where data model accelerations are stored, you can check out the Knowledge Manager Manual. For a custom data model, it's harder to say what the usage might look like, but for the models include in the Common Information Model App, you can take a look at this page in the knowledge manager manual as well as the Deployment Planning section of the ES documentation.
HTH
... View more