That depends on the spatial subdivision method you use, although all subdivision methods (like any compression method) eventually pan out where no further compression can take place, due to data structure overheads and other logical/mathematical factors. An example can be found in octrees. For each node in the octree, a pointer must be kept to it's parent and/or children (depending on how you go about your data sructure architecture), to enable meaningful traversal. Any tree structure may contain n children. The lower the ratio 1:n, the more efficient use of space you gain, and consequently the larger the overheads in tree-traversal since you must have more ancestor nodes to contain the same number of leaf voxels (in your case, roughly 510 trillion of these representing the surface area).
Considering that in your instance the primary issues are storage cost and rendering the whole planet (or parts thereof) from a fair distance, there is no data structure I would recommend over an octree. Mipmapping is a necessity: 12.8 million meters diameter at the nearest higher power of 2 is 2^24=16.8 million. 24 octree levels to traverse would amount to a gargantuan amount of branching -- very costly for GPUs and CPUs alike. But provided you do things right, you will only ever need to traverse a few levels at a time. Given the amount of space required, though, alternatives are few and far between (see below).
The mipmapping capabilities of octrees are what make it such an incredibly powerful tool for large volumes such as that you describe. Unlike all other known subdivision methods (with the exception of KD-trees), the octree keeps subdivision per level minimal, meaning that the visual and physical differences between mipmap levels are also kept minimal, meaning much finer deltas in granularity as you walk up and down the tree.
If, on the other hand, you want to generate a world where hierarchical grid traversal is kept to a minimum, then you will need to trade off space for increase speed.
Speaking of the ideal 1:n ratio, there is no finer structure than the kd-tree in this respect. Where the octree divides in 2 for each axis, resulting in 2^3=8 individual child cells, the kd tree splits exactly once per subdivision level. The problem with this is that you must choose a hyperplane to split by, and this hyperplane could be chosen around any of the 3 axes. While it is optimal in terms of space, it makes 3D traversals (such as during raymarches, a fundamental op when using octrees for physics or rendering) much more difficult than in an octree, since a dynamic portal-type structure must be kept to record interfaces between individual kd-tree nodes.
RLE is another approach to compression, but is in many ways harder to apply to a problem like this (where the base of operations is spherical), since RLE compression is one dimensional, and you must pick the axis that it operates in. For a planet, one might choose the polar axis, but any single-axis choice would introduce certain issues with traversals for rendering and physics when acting from certain non-optimal angles. Of course, you could also run RLE in 3 axes simultaneously, tripling the storage cost, or in 6 axes (-x, +x, -y, +y, -z, +z) as a further optimisation.
So to answer your question (or not!)
I'm not going to go directly into answering what kind of hardware, but I think looking at it from an octree perspective begins to give you an idea of what is in fact possible on what kind of hardware. I would encourage you to go down this route, if you really want to know, it might be easiest to actually implement a simple sparse octree (see Laine's paper in the refs) and place a spherical shell of surface voxels into it, and see what the resultant space usage is like. Step up from there. See just how far you can get before your system memory starts to give out. This doesn't require you to write a renderer unless you want visualisation. Also bear in mind this is best done on the CPU -- GPUs by and large do not have the memory capacity to deal with problems of this scale. This is one of the reasons Intel is looking at moving towards massively parallel processors: the benefits of GPGPU, which is better at this sort of thing, can be applied to a far vaster memory space without system bus bottlenecks to contend with. There are probably others here, or on mathematics.stackexchange.com, who could answer this space-requirement question directly using mathematical means given just the size of the shell and depth of the octree.
In terms of your infinite view distance requirement, sure, but the question always comes down to, "how much detail at what distance". Rendering infinite detail would require infinite resources. That's where variable-per-scene mipmapping comes into play. Also bear in mind that all data structures embody some tradeoff of speed for space or vice versa. That means less/slower rendering, if you want a larger world for the same amount of engineering effort.