Micheal Rys clarifies some details about the XML datatype in Yukon, he writes

...an XML instance can be stored as either an XML datatype or a string type (such as varchar(), although varbinary() works similar as well). Once you store the XML in a string type, the system does not know whether the data is really XML. However, you can use an IFilter, full-text index the column and use the contains function to query for data in the XML. 

If you store the XML instance in an XML datatype, we will use an XML Reader that will parse the XML and store it in an internal binary format that - among other things - is efficiently mappable into an internal relational form that most queries execute over. That relational form can be generated by the primary XML index to avoid the runtime generation during queries and updates (see below). The XQuery and update expressions are being translated into internal algebra operations that work against the internal relational form. This means that we are neither using SAX-based nor DOM-based technology to query or update the document. The queries and updates should be efficient and scalable since we leverage the existing relation engine (extended with new operators) to minimize the number of accessed tuples in the internal relation form.

Note that this is a simplified explanation of what is really going on. Cost-based optimization may chose completely different strategies...

Very interesting stuff, the notion of an XML datatype baked into the SQL Server engine. Truly the rise of the ROX [Relational-Object-XML] database has begun.