Ok, to break down the HTML
FORM#quickContact - Our primary hook, really given the style we don't NEED classes or ID's on any of our sub-elements if we take proper care. We don't need a div around it, we don't need a list inside it.
FIELDSET Because you aren't playing with border or padding on it, we really don't need to play with the fieldset much.
LEGEND Legend placement can be a royal pain, so most the time you are best off just slapping a span inside it to absolute position it. You can use padding to make room, or an element like a paragraph...
P which you have perfectly good text to slap into a paragraph tag.
LABEL Labels can be used to wrap their inputs, which works to our advantage because all we need to do is float these. I noticed in your image they are in the same order as your code, so all that extra wrapping and floating - completely unnecessary! LABEL will do our job!
LABEL SPAN The span are there for padding or other styling hooks.
LABEL INPUT - Just the input. Remember that LABEL's for statement should always be required, and point at the ID of the input it is for.
LABEL BR - When CSS is disabled, make sure they all end up on one line apiece. When developing the markup first and foremost you should be thinking that CSS and presentation doesn't even exist, so what can you do to make it usable without all the eye candy.
DIV - The nested DIV is just a hook to style the submit. I tend to use a DIV instead of a fieldset for these so it's easy to distinguish from the actual data fields. A submit is not a data field, so why would it be in a 'set' of fields.
... and that's really all there is to the markup.
For the CSS, follow along here:
First I use a CSS reset - it's a good idea to use one given that cross browser all those tags don't tend to start out with the same values. There are larger ones, but they're a bit saggy around the midsection for my tastes... there are smaller ones, but they can cause problems with form elements (which would be REALLY bad here)... this is a nice middle-ground, I've never needed more or had success with less.
body - NEVER set px fonts on body if it can be avoided, since that makes your %/em elsewhere meaningless. Even if you are forced to use PX on the document by image interactions, constrained widths or unpredictable element behaviors, BODY should remain %. The background-color is just there to make the form elements borders clear.
h1 - Just a placeholder.
#quickContact - I dropped the width to 768px so that it's ACTUALLY 800 friendly (780 is not) - though I couldn't tell what you were aiming for off that original as your target. The Margin is just to center it, and the position:relative is to prevent the absolute positioned span inside the legend from going off to never-never land. I regrettably am forced to use PX metric fonts because of the MULTIPLE px metric containers and the image interaction... Which of course I load that little phone image as the background here. I also set the text-transform so you don't have to type it in all upper-case in the markup, which looks kind-of 'meh' when CSS isn't present.
#quickContact fieldset - I set up some simple float wrapping and pad the left side to make certain our floats don't try to overlap that phone image.
#quickContact legend span - uses absolute positioning to push that legend to where we want it.
#quickContact p - the text-align is obvious, less obvious is that the entire P rides up UNDER the absolute positioned legend, hence the extra padding.
#quickContact label - here's the neat part about floats - they STACK. So if you have a bunch of them the same size in order, they'll stack one atop each-other in nice neat columns. I pad the bottom just to push them apart a bit. Because our input and span will be display:inline and/or inline-block, the text-align:right will push them all over to the right edge of the label... Do our math right, and we get that 8px right 'padding' without actually stating it. This 'unstated' unused 'padding' (that isn't really padding) lets us avoid the 'perfect width' IE layout headaches where all of a sudden it will decide they need to be one column. (IE - boo!)
#quickContact label span - Setting these to inline-block means we can declare a width on them in standards compliant browsers (in IE7/earlier you can ALWAYS declare a width even when you shouldn't be able to). This width pushes the text over to the left thanks to the text-align... (I'd be half tempted to just let them ride up against the inputs on the right, but it's your layout)
#quickContact label input - Manually declaring a width on these clears up some oddball cross browser issues... Most still won't actually make them the same size, ESPECIALLY using the markup 'size' property - so we undersize these just a hair to account for that. The font size on inputs does NOT inherit from it's parent so we need to set that to match, and I turn off text-transform (which inherits in some but not all browsers) since the user will likely want to type upper and lower case.
#quickContact div - just some padding to make it pretty and a text-align to position that submit. Wasn't actually certain where you wanted the submit, so I took a wild guess.
Hope this helps.