Have you exhausted
http://www.hibernate.org/194.html
I've looked into this idea too. Short of hacking something together for one application / development use My undertanding of it is that for it to work properly a more featureful JNDI implementation is needed inside tomcat.
This all then starts to sound like more featureful application server, like JBoss which includes a HAR Deployer mechanism which effectivly does this. It seperates the SessionFactory and its configuration from the WAR/EAR application which provides a more long running SessionFactory.
But to work effectivly it needs a more featureful JNDI implementation than what I believe tomcat provides. I think tomcat accepts static mapping of only a global JNDI tree from its configuration file but its my understanding that it does not support a dynamic JNDI tree or deal with the security requirements of having an application specific JNDI trees.
The JBoss HAR deployer auto-deploys *.har files and binds the resulting SessionFactory to JNDI dynamically this would usualy be in the scope of the web-application is was supporting.
It would seem a pitty to re-invent the wheel, it would make sense to have a simple JNDI implementation like tomcat does now but also have a pluggable more featureful JNDI implementation as a tomcat add-on that users download on top. This way the base tomcat can stay lean for applications that dont need complex JNDI support.
Then on top of this look at re-using the existing HAR deployer. This approach would seem to bring the most benifit to the most users. We get more features (if we want them) and no bloat to the base code.