You will usually not want to use a complete full-detail map of that size. Usually one would have a LOD system of some kind paired with a tile / VM system.

That said, the image is 5400x2700, which is well within the size that a modern graphics card could stuff into a texture. That would probably even work without too serious performance issues. Thing is, you are unlikely to see the complete planet at once (especially since it's a more-or-less sphere, so even viewed from space, you can at best see 50%) and if you do see it from that far away, you probably don't really need the full detail. You'll need full detail when you look at it from a first person perspective (but then you'll only need a very small part of the texture, plus some procedural noise to simulate the missing detail -- the map is very, very low resolution if you think about it, about 7.4 km or 4.6 miles per texel!).

LOD meaning, level of detail, correct? I'm not sure what VM is the abbreviation of. Where would I go to learn how to utilize these systems properly?

If I could at least produce a rough estimation of the height map, and an outline of that area to physical scale, I could use procedural generation to fill in the missing detail as you mentioned. When rendered, I could begin to refine the details, landmarks, structures, cities, etc. I suppose I could trace the islands; or the area I wish to use in the game, and then scale it to an approximate size for a first person game. I really appreciate the reply, I'll look further into this. It would be rather exciting to produce such a large map.

LOD meaning, level of detail, correct? I'm not sure what VM is the abbreviation of.

Yes, LOD is level-of-detail. VM means "virtual memory", which is basically the same as how VM works in an operating system. Your OS manages the available memory in pages, and when you access some part of (allocated) memory, the operating system will make sure it is resident in RAM. Otherwise it may page it out.

That's very similar or almost exactly what you will want to do. Ideally, in a perfect world, you can keep the whole world in RAM and draw as many triangles as you want per second. Realistically, it doesn't work that way. Therefore, you need a system that puts detail (or mimics detail) where you see it and where it matters, and leaves out what you don't see.

If you stand somewhere on the planet and can see to a distance of, let's say... 2 kilometers, then your task is to make those chunks of terrain (a "chunk" could for example be a rectangular/quadratic area of e.g. 50 meters) resident that are within this area that you can see (and to provide a level of detail that makes sense (more is not "better" beyond some point, only considerably more expensive) and is realizable in real time). It is not even necessary (or possible, for planet-sized worlds!) to actually have "full" detail, say, down to a centimeter or a millimeter in close-up. But it is enough to provide detail that is believeable. Procedural noise, or simple techniques like a bumpmap can help there.

If you search the web for terrain LOD, inevitably ROAM will come up as one of the first hits. Forget about it immediately, do not even waste your time reading the abstract (unless you're really bored). This is early 1990s stuff which was useful when every triangle mattered and when nobody would know what "GPU-friendly" is supposed to mean (since there was no such thing as a GPU). Nowadays, you want to throw a reasonable chunk of data at the GPU and let it do the work, even if that means processing a few too many triangles, it's still faster. The trick is determining what's "reasonable" for every piece, so it looks good.

There exist about two dozen modern variations of what is more or less geometric mipmapping (or clipmapping), using different strategies for determining what to keep resident and what to clip, what LOD to use and how to fix seams, how to morph details, etc.

de Boer's paper as well as Thatcher Ulrich's well-known paper or the works of Hoppe are not precisely le dernier cri (they're all about 10 years old), but I find them quite good to get a general overlook, and no matter what modern algorithm you look at, they're all kind of similar, or variations of these. Yes, some are more fancy than others, but it's basically always the same thing.

The first chapter of GPU Gems2 by Xavier Bonaventura gives an overview on how to do modern tesselation correctly, if you are interested in that (similar whitepaper with demo from nVidia available too).