FWIW, MSFS requires an internet connection (DSL/cable) to fetch all the imagery and geo data.
While we don't have access to such data like google or bing have (at least not under the GPL), there's the option to use osgEarth based imagery.
And that, too, can look rather compelling under certain circumstances, especially in conjunction with OSM vector data or procedurally generated building (autogen).
The "black box" nature of osgEarth makes it not too attractive for people interested in scenery development, but given all the progress in the canvas/compositor areas, it might even become possible to also use a hybrid approach and procedurally "mix" different textures at runtime, using a number of different effects/shaders to make certain "layers" more prominent, and others less so.
With all the advances in CPU and GPU computing it would even be possible to procedurally remove problematic image artifacts (think shadows, cloud layers, actual ground traffic etc) - that's the sort of thing that neural networks can do rather easily.
Basically, we have most of the building blocks in place to pull this off, it's not just being prioritized by anyone as far as I can see. And to be honest, I am finding the increasing tendency to require people to be online to use a piece of software rather problematic - Thorsten and others have repeatedly highlighted how they'd like FlightGear to remain functional even without an internet connection, and that's actual a very valid concern - we are already approaching a situation where more and more key functionality is added with implicit requirements in mind, such as UI functionality that requires a toolkit that other core developers requested to remain optional, or package manager/catalog and hangar systems that are becoming the primary means to download/install and deploy fgdata assets like aircraft and scenery.
In a way, FlightGear is becoming increasingly reliant on external infrastructure, which is a pity given that people can download old versions and build/run those, but newer versions have so many implicit requirements, where features are tied to external data sources/providers, that we're beginning to sacrifice more and more freedoms.
Especially in the Canvas/MFD department, it's now very easy to use external chart providers, so that more and more Canvas based avionics are actually using this method, without providing a fallback. This all started originally when we hard-coded things like the METAR URL.
Technically, this isn't necessary - i.e. the Canvas system is perfectly capable to render its own STG/BTG based charts to an FBO/RTT using code that's been available in atlas/map for decades - likewise, Torsten's mongoose based Phi back-end can easily serve such imagery to another process (web browser), but also to FlightGear itself. And it's not even running in the main loop.
And in fact, ThomasS implemented support for streaming arbitrary Canvas textures over http.
All of which is to say, FlightGear is far better prepared for a holistic approach to scenery than most people seem to realize, but as usual it's hardly common knowledge, because many of these features are poorly integrated - at least currently.
Using the atlas-based approach to creating maps procedurally would mean that FlightGear could become self-contained again, i.e. people downloading fgfs could expect such functionality to work,regardless of external 3rd party data providers.
http://wiki.flightgear.org/Canvas_Tile_Element