I tried this once, and the result was... meh. But! That is partially because I did it cheap/wrong. What happened
- A cubemap was updated at the camera position, every cycle
- Each of the 6 cubemap faces was downsized ("blurred") to 1x1 pixels
- The result was stored as 6 colors (but you can also pass it as a blurry cubeMap texture)
- Objects would get their ambient lighting by mixing between the 6 colors, based on their normals
In essence, this method is more or less correct for objects (very) nearby to the camera, your player character for example. But obviously it's incorrect for other stuff in the scene. that catches the environment from a different position. Now I just tried to achieve very cheap semi-realtime G.I. lighting, but the problem is that the lighting changes with every step you take. If you step forward into a lightbeam, the whole background suddenly changes lights as well.
I'm not 100% sure, but I believe some games actually did use an effect like this (probably combined with statically baked ambient lighting), but "softened" this annoying light-change artifect by smoothly going over from one color into another. You could see this happening in GTA IV, when standing in front of a window in your appartment and then walking a few steps away from it.
Another trick to reduce wacky light-changes, is to exclude small/local lightsources in your initial cubeMap. For an outdoor area, mainly the sky, sun or moon are dominant. So, with some hacks a trick like this could work for you. It's far from accurate, but at least its very cheap & you can use the initial cubeMap for reflections nearby your camera as well.
But more convenient these days is to bake light into "probes", "ambient cubes", or whatever people call it. The idea remains the same, except that you will have multiple probes (sampled as cubemaps) scattered over your world. These probes don't move, and objects/geometry/particles/.../ have to pick the closest probe(s) to fetch their light from. You can pre-bake all your light into these probes, which allows pretty fast and quite decent G.I. However... it's not a realtime, dynamic solution by itself. Of course you could try to update all the probes all time, but it would kill your framerate. There are several tricks being invested by modern game engines to deal with this. Use less probes, spread the updates over multiple cycles, provide fast look-up information so they don't have to render complicated cubemaps, and so on. But so far the bottom line is that all realtime solutions I tried or heard of, are far from perfect. Too slow, too restricted, too memory consuming, or just too ugly.
But you can extend pre-baked probes with some dynamic information. Use SSAO or a similar techniques for local shading. And for day/night cycles, you can store an occlusion value in your probes (or lightmap, or geometry) that tells how much % effect the skybox has on this location. 0% would mean the probe can't see the skybox at all, and therefore won't be litten by it. And otherwise you can add some skybox light, using the surface normals and actual skybox color. Again, a fake. But a pretty cheap & effective one.