I think this is a documentation bug.  The criteria for datetime and time objects being aware are slightly different.  A datetime object d is aware if d.tzinfo.utcoffset(d) does not return None, while a time object t is aware if t.tzinfo.utcoffset(None) does not return None (time objects call utcoffset with None while datetime objects call utcoffset with self).

This accounts for the TypeError in the original example:
>>> import pytz, datetime
>>> UTC_TZ = pytz.utc
>>> EASTERN_TZ = pytz.timezone('America/New_York')
>>> d1 = datetime.time(10, tzinfo=UTC_TZ)
>>> d2 = datetime.time(10, tzinfo=EASTERN_TZ)
>>> repr(d1.tzinfo.utcoffset(None))
'datetime.timedelta(0)'
>>> repr(d2.tzinfo.utcoffset(None))
'None'
>>> d1 < d2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't compare offset-naive and offset-aware times

It looks like this example is flawed according to http://pytz.sourceforge.net/ : "Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones. It is safe for timezones without daylight savings trasitions though, such as UTC."  (If you think about it, the error still makes sense: the UTC time is aware and the eastern time is naive -- any DST time object has to be naive -- but this has more to do with pytz).

It doesn't make sense to have time objects pass self to utcoffset because utcoffset expects a datetime object.  You shouldn't be able to infer what the UTC offset is from a time object unless the offset is constant, in which case you don't even need the time object.  If the UTC offset isn't constant, you need the date, which a time object doesn't have.  I think this is the logic behind having datetime objects call utcoffset(self) and time objects call utcoffset(None).

I've attached a small patch for the documentation.