Not yet, but it's an often-demanded feature, so maybe you would be willing to work on a patch?
Now that I'm looking at the source code, it shouldn't be too hard to make this happen. The simple approach is to query at that revision for each audited class, but if you're auditing 200 classes, that's not good. An alternative would be to store the names of the modified entities in the revision_info table/object in a single field so you know actually which queries to perform - but that's less simple. And I don't fundamentally understand the architecture of the code - I've spent about an hour looking at it.
If you have any recommendations on implementation, I'd be happy to hear them...
If you don't understand something from the structure of the code, I'll be happy to help, either here or on IRC or somewhere else .
How to implement ... hmm ... well we'd want to ask the database which tables have a relation to a specific row in REV_INFO - which isn't a regular DB feature . So either as you say, query every entity or store that together with a revinfo.
In fact, maybe it can be combined with another feature, namely extending revision listeners so that they can obtain the list of changed entities. Then, you could create a revision entity plus a revision listener which stores the names of the entities that changed basing on the list of changed entities, obtained from the framework (that list is available to the Envers insides, so it shouldn't be hard to make it more public).