I have been working on solving the issues involved with planet sized terrain meshes for a while now, and it appears that I-Novae has solved them:

The main issues are GPU precision and jitter issues when using large values on the GPU and morphing LoD details smoothly into the next LoD.

It appears that I-Novae is using some sort of quadtree cubesphere, but the leaf node meshes are being done on the GPU to do the smooth morphing between meshes.

I'm not sure if they are even doing that, but I also don't see how it is possible on an Earth sized planet.

If anyone has any wisdom to share on the topic

I-Novae's version looks quite artificial, not to mention the fact that the morphing is quite apparent.

Outerra (http://www.outerra.com/), in my opinion, does a much better job - and I think if you browse the forums you'll get a pretty good idea of how they achieved it. Don't forget to download their tech demo.

Why would a planet size mesh be a problem? They are probably using some real time procedural mesh generation technique probably seeded from some texture based scheme or painted on which defines how the meshes are generated, mostly mountains and craters, sand dunes etc.. couple this with realistic ground shaders and no vegetation. Surface voxel based terrain generators have been around for along time, slap on nice looking shaders and proper atmospheric light model shader for sky and you got urself a wallpaper worthy engine.

I'm slowly implementing a quadtree cubesphere

That's the approach I'm using at the moment. It's non-GPU so it is easier for me to understand.

Even with the few "pops" of the terrain, that video looks AWESOME!

A pretty good trick for any massive coordinate systems is to represent position using both integers and floats.

Keep the player (camera) centred at [0.0f, 0.0f, 0.0f] and move the world around him/her. You represent the large scale using integers (which are fast to add/subtract) and keep local 'sub-coordinates' in floats. For example (in 2D) the player could be in cell [14, 7] with an offset into that cell of [0.87f, 0.13f]. Assuming the integers represent 100 metre increments, to find out where to draw cell [16, 2] simply subtract them (maybe on the CPU) to get a relative offset of [2, -5]. Then pass the floating point coordinate [0.87f, 0.13f] to the GPU where you subtract again to get [1.13f, -4.87f]. Multiply this by the scaling factor (100 metres) and you have your render position. This way you're never dealing with massive floating point numbers, but only the offsets - which avoids floating point rounding errors. This works just as well in 3D.