I have not worked with KML, but the Linq to XML libraries are essentially a substitute to the XmlDocument, XmlElement, etc, model in System.Xml. From a memory perspective, I do not know if they are any better than your current solution.
One approach I often use is to create a set of data classes that represent the Xml document and then use the XmlSerializer to turn the objects into Xml. I'm fairly this implementation is not a great memory hog and I think, for your purposes, this may make sense.
Here's a quick example. Say I wan to create the following Xml:
<Packages>
  <Package Name="A">
  </Package>
  <Package Name="B">
      <Dependencies>
          <Dependency Package="C" />
          <Dependency Package="A" />
      </Dependencies>
  </Package>
  <Package Name="C">
      <Dependencies>
          <Dependency Package="A" />
      </Dependencies>
  </Package>
</Packages >
You can create the following classes:
class Package 
{
    private List<Dependency> dependencies = new List<Dependency>();
    public string Name { get; set; }
    public List<Dependency> Dependencies { get { return dependencies; } set { dependencies = value; } }
}
class Dependency
{
    public string Package { get; set; }
}
Using the System.Xml.Serialization.XmlSerializer class, you can turn a List into the Xml above.
So if you create an object model for KML that easily maps to the actual KML, like the example above, it should be a somewhat straightforward implementation.