I can't speak to the TEIDisplay plug-in, but I know others in my group looked at it more closely when we paused to survey the landscape of open source e-text delivery solutions. In the end, delivering our TEI content via Omeka didn't make the cut mostly because the XML itself seemed to be buried and was only accessed at the point of rendering transformation. It was unclear how we could leverage the rich-levels of encoding to provide not just display but also discovery modes that would exploit the markup. If we had a project that had mixed-content types that included a few TEI files, say of correspondence, that simply needed to be displayed in a very general-sence, I think the plug-in would serve us well, but not really for a project that is entirely TEI-based.
We have been using for many years California Digital LIbrary's (CDL) XTF (eXtensible Text Framework) software to deliver TEI-encoded texts of all types -- from manuscripts to board of trustees minutues (administrative), from legislative proceedings to literary texts ... and tons more. We mostly deal with level 3-5 projects (as defined by the Best Practices for TEI in Libraries). We are moving away from "boutique" TEI web sites to a more streamlined web development process to achieve what I think it is your implying ... a general framework ( which for us includes what we call "core" XSL) that would work for all types of contents and that would import sytle sheets for particular customizations.
More recently we have been involved in parallel web development with three TEI projects, ranging from levels 3-5, that have taken more of an XTF out-of-box approach but with little sacrifice to the rich encoding [1]. My team mates and I recently gave a talk about our new approaches of web development if you are curious about more of the technical details: http://breeze.iu.edu/p46anbeanm6/. The audio is muted for the first 8 minutes but it's mostly setting the stage for the audience ("why we encode") so it's not anything you don't already know. During that time, I showcase several TEI projects that were developed under the more "boutique" model as a contrast to those that are leveraging "building blocks" for display and functionality.
So, it's hard to answer your question in terms of what needs to be displayed or acted upon against the XML since in some ways a depends on what types of baseline functionality you'd like to support (e.g., linking to page images if present, document-centric navigation, etc.).
With that said, the bits from the Header we typically expose or index for searching: sourceDesc bibliographic information and parts of the profileDesc like classification schemes and terms (textClass), language usage or participant descriptions. As for the text body, what we display will depend of the form and genre of the text, but in the core XSL we have and will continue to develop generic display outputs (i.e., all floating texts that are letters will display blockquoted with a light gray background) unless the particular project is governed by a more faithful representation of the text. In that case, we will display letters as the encoding rendition makes explicit and overwrite the "core" generic display of letters with the project-specific one.
Ack. I feel like I am rambling. It's challenging to define the "general" for a text. Our approach has been rather than predefine the general for the various forms and genres we encounter, we are defining more general treatment of the texts in an organic fashion, and treating customizations as a separate thing that are truly unique to the content. Of course, this has happened by taking stock of the years of publishing TEI projects using XTF and learning from/adapting accordingly.
Another approach taken by John Walsh and his Swinburne Project is to rather than streamline the XTF native XSLs, he has streamlined a way to import his own stylesheets atop of the XTF. It's almost a reverse of our workflow where essentially he's customized the rendering almost entirely but it works beautifully in XTF.
As you work to define a general display for the TEIDisplay plugin, you might consider ways in which you can provide mechanisms for Omeka implementors to incorporate rendering that is unique to the project.
---------
[1] The three more streamlined projects:
Brevier Legislative Reports (http://www.dlib.indiana.edu/collections/law/brevier/)
Indiana Authors in Their Books (http://www.dlib.indiana.edu/collections/inauthors/)
Victorian Women Writers Project (http://www.dlib.indiana.edu/collections/vwwp/)
Each of those web sites contain project information about encoding approaches and technical implementation.
