Well Unity is probably your best option, although one must never forget about p/invoke. Most C++ code can be accessed from .Net with a little extra work but there will also be a slight performance loss. SharpDX uses p/invoke to access the DirectX APIs from .Net, but the performance loss is very minor because it's generated directly from the DirectX SDK header files. C++ CLI might be another option for you, this would allow you to develop your game in C++ and still have the power of .Net framework and the Common Language Infrastructure.
I've asked myself this same question many times. Eventually I ended up developing my own 3D engine for the programming experience. Every 3rd party game engine has it's pros and cons, it's really all about preference. I couldn't find a game engine that suited my needs so I had to write my own.
When I understand something deeply, I'm more productive, I enjoy the work more and I'm able to produce the results I actually want a lot more readily than when I'm tied to someone else's framework. Not to mention I enjoy the task of getting the visuals rendering exactly right. So yeah, learning the 3D rendering skills myself is what I'm doing. I understand that P/Invoke is possible with most 3D engines but there's a lot of screwing around and intermediate layering that needs to be developed to bridge the gap between managed and unmanaged code and that's what I was hoping to avoid if I look at any 3D engines.
Not completely sure what you mean by .NET...I assume you mean being able to code mixed cpp, c# and visual basic? I'm not an expert but I would be a performance hit for that kind of freedom. Although it would definitely make it easier for people to collaborate, maintain and re-use code. You pay a price for that.
I tried the game engine route in early college (Torque Game Engine and Terathon C4) but stopped because I didn't have the skills/experience to understand just what the hell the graphics engine code was doing. I realized I would never be able to make anything truly unique or special without understanding how the graphics worked. Hence I have jumped into XNA and OpenGL to try to write my own engine since then. So yeah...I kind of get where you are coming from when you say you want to build it from the ground up.
Anyway check out Terathon C4...it has come a long way. Although you'll have to stick to CPP in that case...but it's still relatively cheap.
Not sure how you don't understand what I mean by .Net? C# also entails using the CLR and related managed libraries which are compiled to the .Net runtime. So when I say .Net, i mean managed code and in my case, with a focus on C#. Visual basic makes me want to puke. Mixing in C++ defeats the point of the exercise which is to stick to managed code (yes, I know I could use managed C++) but also I don't know C++ very well and that's yet another thing I'd need to learn.
If you're a beginner, you don't really need to be pushing the state of the art. That's probably more harmful than helpful...
If you want to have the ability to make graphics engines as a skill, then it's a really good idea to use a lot of them first. You don't want someone who's never driven a car to be designing one, or someone who doesn't drink coffee working as a barista! 
Many open source engines written in languages like C/C++ will often have "bindings" to other languages, such as C# (much how SharpDX is a C# binding for C++ D3D), e.g.
http://horde3d.org/wiki/index.php5?title=Language_Bindings
If you've got the money, you certainly could be using CryEngine with C#, BTW 
I don't want to *stretch* the state of the art; that's academics and I have my hands full just learning to implement what we already know. I do, however, want access to some of those cutting edge features and techniques that others have already come up with, hence my reference to "state of the art" 3D engines. I know it's not important during early learning, but I'd still like to know that it is feasible that I could make use of some of those features should I want to. Thanks for the reference to Horde3D, that looks pretty decent actually. It hadn't occurred to me that some engines, while not being written in pure managed code, will still come with native bindings to the language/platform of my choice, so that's good to know. CryEngine doesn't require an investment up front, you just have to be willing to pay them 20% of your revenue, which is actually less than if you were developing a $2 iOS game for Apple's app store.
