We are planning on building what you are describing. We call it a "Query Block." Today, we make both a work item field and the work item a first class citizen inside Word. With a Block, we will also make a group of work items a first class citizen and have an associated TeamSpec Skin for the representation of those fields in the document. Imagine being able to change the Skin on the fly or sorting a block in the document by a field. These are the types of things we want to do with blocks. Also, similar to a work item field being out of date (yellow state), imagine a Block being out of date as a result of the query results changing. There lots of little things that are enabled once we get Blocks implemented.
You described the Query Block, which is a group of work items driven from the results of a WIQuery with an associated Skin, but there are other types of blocks we would like to build. For example, image an 'Enumerated Block' where you can add work items to a block without a Query. This is very useful for requirements elicitation since I can just add another work item using the block and an empty Skin. This is very similar to our Clone feature today, but without having to select the section of the document you want to clone.
The third type of Block is the "Tracing Block" which would allow you to create a heirarchical bulleted list based on the links between work items where the top level of the heirarchy is defined by the results of a query. The Tracing Block will allow you to visualize relationships (or lack thereof) between work items.
Once we have the Blocks implemented, automating the process of creating documents (perhaps using document templates as a starting point) becomes much more realistic.
To answer your question, this is not possible today, but it's in our roadmap. We have the foundation to take the next step and make this a reality.