Added support to use with externally compiled Unity scripts, and added a "ViewBinder" script to add declarative bindings 

First of all, thanks for the excellent job of porting Mvx to work with Unity!  You did some great work here porting the awesome MVVM Cross over to Unity.  

Before going into my changes, let me explain the problems that drove me to make the changes in the first place:

All of my Unity code is compiled externally.  So my MonoBehaviours and game code are compiled in Visual Studio, and then I drop the resulting .dlls into the Unity Assets\Scripts folder.  This has worked well for me, except for the fact that NGUI does not support externally compiled game code.  In fact, you can't even access the NGUI controls from an externally compiled code base because they are so heavily dependent on the Unity editor that they are not exposed externally.  The author of NGUI is adamant that it is best this way, and he has no plans of changing this.  

So your original solution of including the Mvx source code directly within the Unity Assets folder makes total sense.  However, this method makes it impossible for externally compiled Unity code to use it.

My solution was to separate the core Mvx code into its own solution / dll, and then only the Unity specific implementation (that you created) goes into the Unity Assets folder. This way, the complied Mvx dll can be referenced by both the externally compiled Unity code and in the Unity Assets folder.  Then the view models can be created in the externally compiled code, which only works with the basic Mvx library.  The AppDelegate, AppSetup and AppStart scripts are placed in the Unity Assets folder as well, since they have to register the Unity specific implementation.  Now we have a nice separation of concerns that allows the externally compiled Unity code to be bound to the Unity views in a completely agnostic way!

I also added a "ViewBinder" script (MonoBehaviour) that is attached to the view (on the UIPanel or UIAnchor GameObject).  This allows you to specify your view - viewmodel bindings without creating a view controller in code.  (This is optional; you can still create a view controller in code as you were doing if you want to).  This way of creating declarative bindings in the view is more intuitive to me since that is what I am used to in WPF.
I updated some of the views in the mvx-unity-ngui-test\TestTutorial project to use the new ViewBinder so you can see how it works.

Also, I have been creating views that are wrapped in an NGUI UIAnchor (none of your examples used a UIAnchor).  This makes it possible to give some basic positioning to your views (center, top right, etc).  I fixed a bug that prevented the correct camera from being assigned when to the UIAnchor.uiCamera when loading one of these views.

One more change that is important:  I renamed your "MvxUnityViewAttribute" to "MvxViewAttribute" and I moved it into the Mvx core code so that it can be compiled and accessed by the externally compiled Unity script code.  I am using this attribute directly on the view model to bind the viewmodel to the view without having to create a view controller class. 

Finally, I split the project into three main folders to encompass these changes:
- mvx-lib
- mvx-unity-ngui-deployment
- mvx-unity-ngui-test

- [mvx-lib] - contains the core Mvx code and a Visual Studio solution to compile it.
- [mvx-unity-nui-deployment] - contains the NUGI (free edition) source code, the Unity specific Mvx code that you wrote, along with the compiled Cirrious.MvvmCross.dll from the mvx-lib solution.  This folder can be easily copied into a new Unity project.
- [mvx-unity-ngui-test] - contains the sample project you created that is updated with my changes.

Again, thanks for your efforts in porting, and to slodge for the awesome Mvx framework.

Let me know if you have any questions or concerns.

Thanks,
Jordan Marr