I suppose the best answer is: "partially".
Building on the example of Person and Address, we add two fields to Address: actualDateStart and actualDateEnd. The registered date is simply the date a revision has been created.
Now, to answer a question: "What did we know on date Z about the (registered) Address of Person X?", you simply need to get that person at that revision:
versionsReader.find(Person.class, X, versionsReader.getRevisionNumberForDate(Z)).
To answer the bi-temporal question: "What did we know on date Z about the Address a Person X had on date Y?", you really need to search the history of Addresses for Person X, but this time, you are only interested in revisions which were before the revision on date Z; more specificaly, you are searching for a revision before Z, for which Y is between actualDateStart and actualDateEnd.
One way to do that is of course get the history of revisions for Person X, and search all revisions before versionsReader.getRevisionNumberForDate(Z). This may not be such a bad solution, if the data is slowly changing (in fact, Envers is designed for slowly changing data), and we don't do a really big number of such searches.
A better solution would be to query the history, and express the condition I wrote above in an SQL query. I am planning to design a query system for Envers (some subset of SQL, expressed most probably similarly to Hibernate Criteria). If you have any thoughts on that, or would like to contribute some ideas - you're of course very welcome :)