I have seen several requests for HV to support database uniqeness constraints.

The general response is "roll your own" validator to perform this check as part of the validation. (prior to INSERT/UPDATE)

I see two issues with this.

View validation
Validation can be done in the view layer, and in this case, the database can not be checked (w/o significant overhead).
While it appears possible to address this by depending on injection of the EntityManager via the @PersistenceContext annotation, the validation in the case where the EntityManager == null can only assume the value is valid.

Costs
Such validation is pretty expensive One or more SELECT(s) to verify uniqueness of column(s).
In the above approach, this must be performed before every insert or update.
This is unnecessary, since the database will enforce constraints and throw some flavor of JDBCException.
It is however ugly to determine what constraint was violated based on the PersistenceException.

It would be preferable to only execute such a validator on a failure.

Has there been any thought to allow for validations to be performed on the entity class after the persistence action fails? (and not at all on success?)

In this case, instead of a PersistenceException, the InvalidStateException would be returned to the client.
Would this break the JPA specification?