For anyone who cares. 
I just spent the week converting the Xamarin Forms Gallery Samples from a code-centric (C#-based) solution to a Xaml-based solution. You can find my fork/version/work here:
https://github.com/Michael-DST/xamarin-forms-samples/tree/master/FormsGallery
This was my first real-life work with Xamarin.Forms and I have to say that it was a fun and enjoyable experience. I was able to really get a crash-course in Xamarin.Forms and learn all of its controls in one fell swoop. I am sure there might be a glitch here or there in the current version. But, for the most part, it is working as expected and I am happy with the result.
(I should also say I am only able to test it on Windows Phone at the moment as I do not have a Droid/iOS license just yet. All of my work was done in the shared assembly with the exception of upgrading projects to 1.3.5 so Droid and iOS should work as well -- please let me know if this is not the case!)
I was able to pretty much do whatever I wanted to get things converted and working in Xaml. As you know, Xamarin.Forms supports markup extensions which was the first thing I sought out when exploring it (and fell in love with it immediately!). For whatever perplexing reason they have, MSFT did not ensure that these very powerful instruments were preserved when designing WinRT. Using markup extensions, I was able to overcome any significant issue I encountered, while accomplishing the goal of completely implementing the pages in a Xaml-based fashion.
(As an aside, I personally am still dumbfounded on why MSFT continues to overlook this impressively powerful concept in WinRT. No other markup language features this incredible feature and it is primarily why I have such a strong passion for WPF/Silverlight and now Xamarin.Forms).
I did find some issues during my efforts, but none of them were show-stoppers. Probably the biggest bug I found was that NavigationPage does not support direct content:
https://bugzilla.xamarin.com/show_bug.cgi?id=27711
But, I was able to get around this by using a (GUESS WHAT??? Yep.) markup extension here:
https://github.com/Michael-DST/xamarin-forms-samples/blob/master/FormsGallery/FormsGallery/FormsGallery/Support/NavigationPage.cs
Also of note, Xamarin.Forms doesn't (currently) support DataType-based DataTemplates, but I was easily able to get this working by quickly throwing together this little gem of a (guess again???) markup extension:
https://github.com/Michael-DST/xamarin-forms-samples/blob/master/FormsGallery/FormsGallery/FormsGallery/Support/DataTemplateConverter.cs
In case anyone is interested, here are the other issues I found while converting the Forms Gallery from C# to Xaml:
Visual Studio Extensions: Invalid File Allowed to Build
Xaml is not Properly Registered as Designer vs. Code
Excluding a Xamarin.Forms Xaml File and Then Including It Does Not Work as Expected
ContentView.Content Property Is Not Bindable
First chance exception of XamlParseException When Viewing Xaml Page That Uses ConstraintExpression
Content Property for Page.Resources Does Not Work As Expected
Invalid Binding Markup Works, but Should Provide an Warning/Compile Error
I would not consider any of these show-stoppers or critical. I think this really speaks as a testament to Xamarin.Forms and the team developing it. This project is nothing short of awesome. Really impressive stuff! I am very happy to be working with this technology and look forward to its progress.
Anyways, I wanted to post this in case someone else might benefit from the code. I have had my nose in Xaml-based technologies since about 2006. Almost a little less than a decade now. There are a lot of great features to it and it is so expressive that you can basically do whatever you want to do code in markup. This allows you to design your solutions with unparallelled separation, leaving object definitions and serialization to be relegated in (very powerful) markup, while all the processing is left in code. Each side is left to do what it does best. Perfect harmony.
Xaml is preferred over code wherever possible as it is essentially structured and constrained input. That makes it cheaper to develop and to maintain over the lifetime of an application. And, since it is strongly-structured, it is designer-friendly as well. Finally, Xaml is language-agnostic (unlike JSON, where in its very name lies a violation of this principle) which in addition to being cheaper to maintain, also makes it so that it can work with C# and VB.NET (for when XF supports this and more).
I will end with saying that I am open to any feedback. Please let me know of any comments/questions you have for this code and I will do my best to address them.
Happy Coding (Days Are Here Again)!
Michael
(Oh, and also, THANK YOU Xamarin!!!)