Yes - Unity itself shouldn't limit you. And as others have written, Open World games are not that much more performance intensive than indoor scenes...

True, it is easier to use culling systems when you have rooms and walls naturally limiting view range. But you can do the same in an outdoor scene. This is what is usually happening in most outdoor games, by creating the terrain to limit viewdistance, and using probps to fill the gaps where terrain doesn't do the job, you could without problems limit viewrange to 500m or less max, without the player noticing much. Then you can use a culling system (I think Umbra should be available in the personal edition with Unity 5) to make sure the parts of the scene that are not visible will never reach the GPU.

Of course there might be spots where you want to present a more long distance shot.... you could use special geometry, or just simple billboards in these cases (also done in a lot of games... when there is a vantage point where the player can enjoy the scenere in the distance, this scenery most probably is not normal game object geometry, but special "far distance" geometry).

Of course, there are much more things you can do (like optimizing models, both reducing polycount and combining meshes where possible, baking all textures to a single atlas and single material, making sure you tighly control the amount of geometry you place in the scene, and so on).

There are some systems and tools inside the Unity engine that can make this work easier for you, most of them where part of the Pro edition until Unity 5, and I am not 100% sure if they are available now in the Personal edition, but these are what you could use:

1) Make sure all static geometry is set to static so the engine will batch it all together and send it to the GPU in the least amount of drawcalls possible (if static batching is not available in the personal edition, you could still do this manually by exporting the scene to a Polymodeller like blender, and combine the meshes there).

Of course that means, if you really want to take advantage of static batching, you should ONLY leave dynamic what really needs to be dynamic. Every dynamic mesh will add to your drawcalls!

2) Use occlusion culling, as said before. Beware, Occlusion Culling has a set overhead, be careful to not make it too fine granular in a too open scene, or it might actually decrease your performance (it needs to do some processing now to actually find out what is visible for the camera, so if there is not much to cull and to much data to process, in the end you will spend more performance on finding the visible parts than you can save from culling the invisible ones).

3) Make sure your terrain is not to high resolution! That can really slow things down. If you are using something crazy like 1X1m Heightfields, you should set the pixelError setting in the Terrain settings a little bit higher (which will decrease the amount of polygons used for the terrain), else the terrain will eat up your performance.

4) If you use realtime lighting, make sure the shadowdistance is not set too high. If you can, bake lightmaps.

5) even in deferred, control the amount of lights you are using. Cost per light is low, but still there. If you do crazy things like adding 100 lights to the scene, they will slow down the performance cosiderable. Lights never get culled AFAIK, so if you spread 100 lights in the scene, they will always be processed, no matter if visible or not.

Now, about streaming, I cannot help you there, as I never tried that in Unity....