I don't know of a fully accurate and reliable way to track this.
One way to get at least something potentially useful is to keep snapshots of sys.dm_db_index_usage_stats, specifically the
user_lookups column for index_id 0 (RID Lookup) and 1 (Key Lookup). This DMV can be reset for many reasons, including database or instance restarts. Rebuilding (but not reorganizing) and index also clears the related DMV entry on SQL Server 2012 and later, which can make things more difficult. You will need to capture information fairly regularly and use a heuristic to decide if the DMV reset between captures.
The index usage stats DMV also only returns a count of the number of times a plan containing a Lookup is executed. A plan that contains a single Key Lookup will increment the counter by 1, regardless of the number of lookups actually performed. It will also increment even if the Lookup is not executed at all.
The sys.dm_db_index_operational_stats DMV records the number of singleton lookups actually performed, but does not distinguish between singleton seeks on the index directly, and those that result from a Key or RID Lookup, so it is not useful for your purpose.
Singleton seeks are another name for Probe Scans as reported by the Access Methods Object. There is no way to distinguish between a 'normal' singleton seek on a unique index, and a singleton seek resulting from a Lookup. This means the Access Methods Probe Scans counter is not useful to you. The AM counters are very noisy anyway, and there's no way to correlate the counters with a particular index.