Klucz obcy to pole user_id w tabeli addresses.
To, co na końcu zacytowałeś, to constraint (ograniczenie/warunek) na kluczu obcym - czyli wymuszenie integralności danych po stronie silnika bazodanowego. W RoR się (domyślnie) tego nie robi, zakładając że ten warunek i tak zostanie spełniony przez sensownie napisaną aplikację. Życie uczy, że constrainty tylko utrudniają życie - zwłaszcza migrowanie i usuwanie rekordów.
Jeśli chodzi o constrainty to w przyjęło się zakładać je ręcznie tylko w środowisku produkcyjnym bo w przeszkadzają w testach i deweloperce - dlatego migracje ich nie zakładają automatycznie.
Poza tym RoR ma trochę inne podejście tzn. sprawdzanie integralności w bazie przełożone jest z silnika bazy na aplikację. Poczytaj o opcji :dependent w definiowaniu relacji.
Takie podejście ma tę zaletę, że cała “wiedza” o działaniu aplikacji jest zawarta w kodzie aplikacji a nie rozrzucona (tzn. trochę w aplikacji a trochę w bazie). Wielu DBA powie jednak, że to jest beee - wszystko zależy od wymagań IMHO, jeśli chcesz założyć ręcznie constraint to Rails’y Ci w każdym razie nie przeszkodzą to zrobić na serwerze produkcyjnym.
Gwoli uzupełnienia tego, co zostało już napisane w niniejszym wątku, dodam cytat z “Agile…”:
[quote]Many Rails developers don’t bother specifying database-level constraints such as foreign keys,
relying instead on the application code to make sure that everything knits together correctly. That’s
probably why Rails migrations don’t let you specify constraints. However, when it comes to database
integrity, I (Dave) think an ounce of extra checking can save pounds of late-night production system
debugging. You can find a plugin that automatically adds foreign key constraints to models at
http://www.redhillconsulting.com.au/rails_plugins.html[/quote]
Czyli wystarczy, że zrobie relacje w modelach i wszystko powino działać w bazie zgodnie z założeniami?
Biorąc pod uwagę railsowy dorobek Dave’a Thomasa,szacunek, jakim cieszy się jako railsowiec (nie umniejszając mu nic jako pragmatycznemu programiście!) oraz jego zrozumienie RoR, nie podchodzę do jego wypowiedzi zbyt serio, a już na pewno nie na kolanach 
@Miras: tak.
Też zlewałem constrains w bazie aż do ostatniego projektu. Musieliśmy zmigrować dane z MySQL do Postgresql (naszego zwyczajowego silnika) i jednocześnie zmienić schemat na normalniejszy (sic!) i bardziej przyjazny Rails.
Coś mnie tknęło i zacząłem dodawać te wszystkie references i not null, itd. Okazało się, że oryginalna baza miała sporo niewłaściwych danych: ‘wiszące’ artykuły, pokasowanych userów. Migracja zajęła nam więcej czasu ale dzięki temu możemy bardziej ufać bazie 
Miało to też jeden dodatkowy plus: łatwo zaczęliśmy wychwytywać nieprawidłowe fixtury. A to pomogło przy testach.