<p>I find it much easier to write MXML classes with embedded Script than trying to make an actionscript file.</p>

<p>I was wondering however what kind of overhead there is of using an MXML file - in terms of file size. I'm not especially concerned about performance, but if that is relevant would be interested in any findings.</p>

<p>Obviously I'm talking about UI components that have layout. MXML is MUCH easier to visualize and modify but I'm unclear exactly what it compiles down too. I'm hoping there is a negligible difference.</p>

If you're going for the same functionality, MXML is not going to make your swf any bigger.
The thing that's affecting size is using the Flex SDK and its components. Whether you declare them with MXML or AS3, you're using them and their code is being built into the swf. By the same token, if you're referencing the Flex RSL, and thus avoiding building the Flex stuff directly into your swf, it will be the same size either way. Data Binding does create a lot of events and listeners, so that might cause some bloat, but not any more than if you declared the data binding mechanism with the AS3 utility functions.
Since MXML does generate intermediate AS3 code, it might be more verbose than you would care to write on your own, so you could see some additional size from that. To peek at it (which is good for understanding in general) you can look at with the compiler directive to keep the generated code.
From:
http://www.flashguru.co.uk/flex-2-compilation-hidden-goodies
Right-click a Flex Project in the Navigator Panel.
Select Properties from the Context Menu.
Select Flex Compiler in the Properties Window.
Enter -keep-generated-actionscript into the ‘Additional compiler
  arguments’ field.
Click ‘OK’ to apply the changes.
Build your Flex Project by clicking the Run button.
Right-click your Flex Project again in the Navigator Panel.
Choose Refresh from the Context-Menu.
A new folder should appear under your Flex Project in the Navigator
  Panel, named ‘generated’
This is a good thing to do once you get into debugging and profiling your project, since you can really see where the compiler is doing the right (or wrong) thing.