While displaying a textured sphere is easy, getting to procede from high orbit to actual land fall and dynamically scale up isn't so easy.  By definition, you are defining a whole planet which is a really big place.  That means lots of memory or hardrive space to store something on that scale.  The inital answer is just use a texture and that works to a point.  The PROBLEM with that is, it really won't go down to "walking on the ground" level and it really starts to get distorted at the poles.

Down around the equator, the distortion is so minor you don't consider it, but as you can see at the poles of the planet, the idea of a texture can get messy.  That isn't so much a problem (but still is) with a color texture wrapping a sphere, but when you try to do X and Y shifts the concepts no longer work.  Even if you simulate it with spherical coordinates (theta and phi, ie. theta being lattitude and phi being longitude), close to the poles, you are litterially running around in circles when you go along the "X" axis.

The current "solve" for this is you don't use X and Y, but a isohedral format.

Now there are no "poles" per se.  This is based on a isohedron.  (think of a 20 sided die, although the picture is one subdivision down).   While this works, if you noticed, some triangles are layed out in a hexigonal pattern and some in a pentagonal pattern.  This creates it's own series of problems, so my original idea of just doing hexigons won't really work globally.  The isometric triangles still will, however, but now the trick is to get them to play nice.  I have an idea via linking triangles together, but again, on planetary scales, that gets very memory intensive. I have ideas for optimisation, but then things get unlinked, so there are still problems to solve.

Of  course, none of this solves the issue when you get below the original heightmap threshold, which will have to be handled by something procedural like Perlin noise.