The wording of your question suggests a misunderstanding of how Unity works (please correct me if I'm wrong), so I'm going to recommend you just try out Unity. "Unity3D scripts" are just .NET classes that inherit from UnityEngine.MonoBehaviour or UnityEditor.EditorWindow.
There's nothing stopping you from writing freestanding C# classes or pulling in .NET libraries (assuming they are compatible with Unity's version of Mono, which seems to cover the important parts of .NET 3.5). Whenever you create a dependency on something not included by default in a Unity release deployment (ie: System.Xml) Unity sees your using statement, sees what members of that namespace you use and automatically bundles in the correct assemblies from the standard Mono distribution that it includes (you can also drop in your own .NET DLLs).
So long as any third party .NET code works in the .NET 3.5 subset that Unity's version of Mono supports, you can use it. Be wary of libraries that provide too much abstraction, though, or at least use them sparingly. This is game development, not enterprise software.
We do some dynamic scene construction in our Unity project, and all of the data for that is handled in pure C#, no UnityEngine namespace references except for where it wouldn't make sense to re-implement a data type that Unity already has (ie: Vector3). We reference System.Linq and could use JSON.NET if we wanted (but that lib's a little fat, so we use LitJSON instead).
Is there a .net engine out there that helps me with asset loading, animations, physics, transitions, etc. with a scene editor, but allow me to plug it into a visual studio .net project?
Do you want to plug into a VS project because you really like VS and want to manage the project entirely from there, or is it that you want to use standard .NET assemblies? If you want to contain your whole project inside of Visual Studio, then your main options are things like OpenTK, SlimDX, MonoGame, or XNA and other's engines built on top of those. You'll also have do some work to build your own scene editor or integrate someone else's into your game.
I think you'll find though, that having your code and other assets exist in separate worlds can make things much simpler, especially if you bring an artist in later into the project.
If you want to step debug inside of Visual Studio instead of MonoDevelop, you can look at UnityVS.
And however you implement your backend is completely independent of your game's client code. The only mutual dependency between them should be the communication protocol.
