This is not definitive proof but just my opinion based on what I learned from a PluralSight course Paul Randal did on wait stats.
PREMEPTIVE waits are indicative that SQL Server Operating System (SQLOS) has to change a thread to preemptive mode to handle something outside of SQL Server, at the OS level.
Now as you have already determined this types of waits are not documented much at all. There are a few you can see documented in BOL under the
sys.dm_os_wait_stats DMV but it is not extensive. In most cases the calls being made to the OS are via Windows API calls. So what I ended up learning from the course is that if you take off the
PREMEPTIVE portion of the
PREEMPTIVE_REENLIST you end up with the name of the possible API being used:
REENLIST. So if you take that and start searching around on the web you can try and deduce what it means.
So my deducing would be that I came across this MSDN article on
IResrouceManager::Reenlist there are also other MSDN articles on similar named methods that all discuss a
TransactionManager. It is not the content that catches my eye but the section of MSDN where this article is located: DTC Interfaces. So you don't specify this level of setup for your server but I would make a hunch that you are using distributed transactions. This can come from making remote calls to other instances/databases or if you are working on a clustered instance. If you actually read a statement from the MS DTC Service, although it is from SQL Server 2000 you might catch the key word that caught my eye:
One or more servers running SQL Server can then be instructed to enlist in the distributed transaction and coordinate the proper completion of the transaction with MS DTC
Just my opinion...