Yea, fine control over what IL F# emits can be annoying when dealing with certain libraries that make certain assumptions :). Most libraries just expect all code to be like C# would generate it (this gets really nasty with expression trees).
When doing object interop with serialization frameworks, you might need to just use the F# OO types. With these, you can generate constructors or read/write properties as you see fit. I agree though, it sucks since record types are a lot nicer to deal with.
If you really wanted to use records, you could use F# reflection and hack something up to generate a type that looks like whatever the framework expects. Pass that type in, then pop it out to a record automatically. Won't work for all APIs, but might work for this one.
BTW, if you go the F# OO route (which is still easier than using C# and doing interop), here's how it'd look:
type FooReadWrite() =
let mutable field1 = ""
member x.Field1 with get() = field1 and set(v) = field1 <- v
type FooReadOnly(field1: string) =
member x.Field1 = field1