I don't know a whole lot about the actual implementation of it and I doubt it's the usual way to handle it, but to me ClipTextures or (Sparse) Virtual Texturing comes to mind.
Essentially -from my perspective at least- the idea is to keep only the relevant part of a very large texture file located on the hard-drive in system memory and an even smaller "clip region" of it in the GPU memory. If the position in the game changes now, and therefore the region of the texture required for rendering, the missing texture data is streamed to the GPU memory from the system memory. By adding only the missing texels and removing texel that are far away from the game view, the amount of data that needs to be streamed is limited. Also the part of the texture present in system memory should be updated accordingly, to keep longer loading times -due to the hard-drive access- away from the rendering.
It basically is sort of memory cache implementation for textures and I image a clever caching strategy and prediction of what texels will be needed next, will of course be necessary.
If you are interested, for further reading you might want to start with these slides from Id Software about virtual texturing (in Rage): Id Tech 5 Challenges. Or also this (longer) SGI Article on Clip Textures.
Also, since you mentioned retina displays. I believe most modern GPUs should support textures up to a size of 16k times 16k (at least even my 4 year old Notebook does), which should be around 50 times as much area as a retina display offers and still several times as much in one dimension. But that's just playing with numbers of course :)