Keeping iterator in consistent state
No SQL Server does not hold a latch. The storage engine keeps track of the current index scan position using a "cookie". The cookie is revalidated if another process takes a latch (of a type that means the page might have been changed) on the same page since the cookie was acquired.

If the cookie (scan position) is no longer valid, the b-tree structure is traversed (using key + uniquifier information stored in the cookie) to reacquire the correct position, and the cookie updated.

In case it is of interest, here is a stack capture when the saved position is validated:



And another one just after cookie validation has failed due to a concurrent incompatible latch. The engine is repositioning the scan position using a seek to find the correct new position:



There are performance counters related to cookie activity, for example Scan Point Revalidations/sec and Used page/leaf page cookie.

There is no public documentation that describes exactly how this all works. The details above are based on observations, subsequently confirmed in conversations with Paul Randal and Bob Ward.