There are a couple accessibility concerns with this particular implementation.
First they're using negative positioning to hide this placeholder label; negative positioning like this removes text from the screen, but screen readers still read text formatted like this in general, resulting in different presentation for screen readers and screen viewers.
More importantly, it appears that common screen readers will not read more than one label associated with a form field; apparently JAWS in particular will read only the last label associated with the field. A little more reading on HTML Lables and accessibility is here as well.
It's important to note that the HTML 4 spec explicitly allows multiple labels:
The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control.
The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute.
JAWS and related screen readers only reading one label is incorrect behavior so it's not going to cause a validation error, it is valid. All the same a great deal of screen reader users will only hear one label, and worse some will hear the first label and some will hear the last label as noted on 456ereastreet.com:
Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document’s source order.
JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus.
As a sidenote, HTML5 provides the placeholder
attribute for input fields which meshes with accessibility and does not replace a label element, but you'll probably want a javascript fallback for users on browsers that do not support HTML5.