This is a review from Review Bot.
  Tool: PEP8 Style Checker
  Processed Files:
    reviewboard/accounts/models.py
  Ignored Files:

Col: 1
 E302 expected 2 blank lines, found 1

Col: 58
 W291 trailing whitespace

Col: 1
 W391 blank line at end of file

This is a review from Review Bot.
  Tool: Pyflakes
  Processed Files:
    reviewboard/accounts/models.py
  Ignored Files:

 undefined name 'this'

 undefined name 'this'

 undefined name 'this'

Managers are special classes that manage models. This doesn't look like a manager. Instead, it looks like it's a container for other classes.
I think we should use "Notification" terminology, and move all this to the notifications/ directory. Managers live in managers.py files, and models live in models.py files.

This would be a Model.
I would just call it "Notification".

General comments on docstrings:
They must always be in one of the following forms:
"""One-line summary."""

or:
"""One-line summary.

Multi-line description.
"""

No line can exceed 79 characters.

You should instead use help_text (if you want this user-visible), or use:
#: blah blah

for defining comments on a field. (This will then be represented in any codebase docs we generate.)

"sender" and "recipient" are probably better terms to use.
Make sure you use related_name= on these, or you'll have collisions. Names like "sent_notifications" and "received_notifications".

I think a BooleanField would be sufficient. "read" or "new" or something. It'll take less space, is faster to index on, and I don't think we need anything more complex.
If we do need states, then we should just have flags for the different states, and store a 1-byte CharField for them. See what we do in ReviewRequest for 'status'.

This is state in the database that can be queried. There shouldn't be any state locally here.

You'll almost never have an __init__ for models. You should have defaults set on fields instead.

I'm not sure why this is separate from the stuff above? Or why it's a nested class?