the Jackrabbit Repository and the associated JSR standard for Java Content Repositories alone provides a fairly low level persistency API, which you could probably use to build Repositories for Domain objects, mapping the data to repository structures such as JCR nodes/properties. You will use the JCR API located at the javax.jcr.* package to manipulate the repository (and for maximum portability). In a sentence, you can use Jackrabbit to replace your database.
A quick google search showed that there are indeed projects that aim to provide similar convenience wrappers to the ones you probably know and love for JDBC and Hibernate, only for JCRs. I found for example the Spring Modules project: http://java.net/projects/springmodules/ which was unfortunately last updated about two years ago, so it is still on JCR 1.0. For sample usage take a look at http://java.net/projects/springmodules/sources/svn/content/trunk/samples/jcr/src/org/springmodules/examples/jcr/JcrService.java?rev=2110
Still, you could probably write your own JCR2Template without a lot of effort, and encapsulate the repetitive tasks such as connection and exception handing by using the Template Method pattern.
So as for the request mapping, you can run the JCR on a separate server, just like you would with a relational database, and connect to it via RMI. Here's an example: http://dev.day.com/content/docs/en/crx/current/developing/accessing_jcr_connectors.html
I would consider this the "clean" way to use a JCR in Spring MVC applications.
As for the WebDAV saving part... I know Jackrabbit does indeed support the mounting of Repositories as WebDAV drives, but I don't really have any experience with it and I honestly can't imagine a way to tell Word to upload a file upon edit somewhere... But I am not a Word expert at all, sorry....
Now ... the Apache Sling Framework on the other hand provides an interesting approach to build RESTful applications, that integrate well with the repository model and some higher level abstractions of the Repository structure. The way Servlets are resolved in Sling, however is completely different from plain Spring MVC (see http://dev.day.com/content/ddc/blog/2008/07/cheatsheet/_jcr_content/par/download/file), so it would a bit of work to reconcile both approaches.
Hope there's some info in there you can use.
Cheers,
Johannes