I would like to get an idea of what percentage of a frame I should expect to spend rendering terrain in an outdoor environment.
The environment I am going for is something similar to Oblivion or ArmA, as seen in the following images:
ArmA II
Oblivion

I know it is a very broad question, but I would like to get at least some baseline idea of the target performance to shoot for. Right now my best guess is 1-99%, I'd like to get the margin of error down to 20% or so

Your guess looks good. Seriously, looking to optimize performance before you've optimized the design is a backwards approach = Premature Optimization.

Write your best code and see what you get. If you don't like the performance, profile your code to determine where the time is spent and further optimize the code involved.

If you spend 20% or 90% of the time rendering terrain, and you're achieving the performance you want, you're where you want to be, I would think.

I want to get an idea of what kind of performance to expect not for optimization, but so I can get an idea of what kind of terrain I'll be able to render when more stuff is implemented. I can render a massive amount of terrain at respectable frame rates, but I know that when I also have to render character meshes, ground clutter, trees, etc, the amount of terrain I can render will have to drop to maintain those frame rates.

I would estimate 40-60%, but not because terrain is particularly expensive. Performance cost is not additive these days. Modern games are generally pixel-bound, so the cost of rendering a screen's worth of terrain is not much less than the cost of rendering the whole game. By adding more objects to the scene you add N pixels worth of the new objects, and occlude N pixels worth of whatever is behind them. Occluded pixels have very little cost, either due to early z rejection or to the use of deferred rendering.

You also need to figure on about 15-25% of the frame time going to postprocess effects, and that part really is additive.

I would estimate 40-60%, but not because terrain is particularly expensive. Performance cost is not additive these days. Modern games are generally pixel-bound, so the cost of rendering a screen's worth of terrain is not much less than the cost of rendering the whole game. By adding more objects to the scene you add N pixels worth of the new objects, and occlude N pixels worth of whatever is behind them. Occluded pixels have very little cost, either due to early z rejection or to the use of deferred rendering.

You also need to figure on about 15-25% of the frame time going to postprocess effects, and that part really is additive.

Cool, I'll have my art guy plan for approximately 60% and we'll see how it goes

I would like to get an idea of what percentage of a frame I should expect to spend rendering terrain in an outdoor environment.
The environment I am going for is something similar to Oblivion or ArmA, as seen in the following images:
ArmA II
Oblivion

I know it is a very broad question, but I would like to get at least some baseline idea of the target performance to shoot for. Right now my best guess is 1-99%, I'd like to get the margin of error down to 20% or so

I wouldn't think of it in terms of how much time should be spent just rendering terrain. Think of it like this...what is your target frame rate? If its 60 then you have 1/60 seconds to update and draw your world. That's ~0.016667 seconds. Obviously this is not considering a multi-threaded setup. Anyways, that basically means it doesn't matter how much time is spent rendering terrain as long as you have time to do everything else in the same frame. So if you spend 90% of your frame drawing terrain that actually might be totally fine if you can squeeze everything else in. Its a balancing act. You actually might NEED to be at 10% of your time to get it all done in the frame. You want to take a defensive step when coding it up by not doing anything egregious. You want high level of optimization in your algorithms. However, don't get lost in trying to hit any other target time spent rendering terrain that's not going get you back more frames than you want. Make sense?

So if you spend 90% of your frame drawing terrain that actually might be totally fine if you can squeeze everything else in. Its a balancing act. You actually might NEED to be at 10% of your time to get it all done in the frame.

Well I'm trying to get an idea of how much a terrain-based renderer (one where there is a lot of terrain, a decent amount of ground clutter, and relatively little character models) usually spends on the terrain rendering portion.

You want to take a defensive step when coding it up by not doing anything egregious. You want high level of optimization in your algorithms. However, don't get lost in trying to hit any other target time spent rendering terrain that's not going get you back more frames than you want. Make sense?

I'm not trying to preemptively optimize anything just yet, I just have a basic terrain renderer in place, but no culling for non-terrain geometry, no post processing, no fancy shaders that will be used on the non terrain portion of the rendering. I know that I can push a certain amount of terrain through the pipeline and hit 60 fps, and I know that when I do get all the bells and whistles implemented that number will drop. I'm simply trying to get some idea of how much it will drop by, both out of curiosity and so that I can tell my art guy what kind of terrain to be designing/expecting.

I wouldn't think of it in terms of how much time should be spent just rendering terrain. Think of it like this...what is your target frame rate? If its 60 then you have 1/60 seconds to update and draw your world. That's ~0.016667 seconds.

The two things are directly related; 1/X*Y = Z, where X is my target FPS, Y is the portion of a frame spent rendering terrain, and Z is the amount of time that will be spent rendering the terrain.