I will suggest that the p called “label” be replaced with the legend of a fieldset, simply because a p is not a form control and you magically get better accessibility with the switch to a legend from a p.
When I write labels wrapping inputs, I put a space between the end of the input and the beginning of the label text, so I mean:
<label [b]for="less2months"[/b]><input [b]id="less 2months"[/b] name="less 2months" type="radio" value="less 2months"/[color=red]> [/color]Less than 2 months</label>
Note that wrapping inputs in labels, while perfectly legal, still causes enough hiccups in some Accessibility Technology (and also a strange intermittent issue in Safari on OSX) that many people avoid this setup, even though it gives you “blocks” (the labels) for styling and positioning without needing to add divs or something.
I’d also be wary of setting the height of the labels to 0. That sounds kinda scary.
Anyway if the label and the input were both inlines, or inline-blocks, they could both be given “vertical-align: middle” (or top or bottom or whatever) that helps them line up the same (IE won’t necessarily cooperate). Or, since you’ve set a line-height on the label, you could explicitly give that same line-height to the input too… I notice if I set line-heights globally, inputs still seemed to turn to the browser’s styling instead. I’ve started always setting explicit line-heights on my inputs now too.
Either of those two things (or both) may automatically help any alignment issues, since those are pretty common in forms.
Also, while we harp on not using tags for “presentation” in favour of CSS, if you decide you don’t feel safe relying on CSS to give the user knowledge of which label goes with which input (a usability issue), you could use <br> tags after each label-input pair. I have done that, and they can be overridden themselves with CSS. This would only be where the break conveys meaning by showing explicit grouping of elements (similar to why we use <em> and <strong> instead of just styling <span>s, even though no machine we know of actually knows what <em> and <strong> actually mean, so they’re just semantics for semantics-sake anyway).