The main value proposition of Spring's Hibernate support is that is provides both transaction management *and* Session lifecycle management, while EJB CMT just provides the former. With EJB CMT, you need to care for the Session lifecycle yourself, typically with some custom ThreadLocal. Spring provides convenient, pre-built solutions here.
Furthermore, Spring provides sophisticated means to set up and wire your resources and application objects, in particular your SessionFactory, your DAOs, and your business facades. Handling a SessionFactory can cause some headaches with EJB, because you need to guarantee singleton semantics for it, rather than one SessionFactory per pooled EJB instance.
Essentially, Spring's transaction management is a lightweight *alternative* to EJB CMT, allowing you to code your DAOs and your business facades as POJOs rather than work with local SLSBs. Spring's services are available in any environment, be it in plain Tomcat or a standalone application - no EJB container required.
http://www.hibernate.org/110.html gives an introduction. Have a look at the Petclinic sample app that comes with the Spring distribution for a working example: It's "clinic" business object uses Spring's declarative transaction management with Hibernate as data access strategy. Note that Petclinic works nicely in plain Tomcat!
Juergen