I think this can be said more simply.

Unique constraints are a logical feature: like all constraints, they are something you say "must be
true" at all times. The database must respect this, always. It is a requirement, with nothing said
about how this should be accomplished inside the black box. The database is free to accomplish this
any way it likes, so long as it does.

Unique indices are a physical feature: they are a tool used by the database to insure the above
constraint, but they are not required. In a pinch, a DBMS should be willing to do a full-table-scan
looking for possible duplicates. It could use a non-unique index, too. There's some efficiency
gained by using unique indices with unique constraints: the index is guaranteed never to be asked
to store duplicate values, so that's one less thing it has to worry about, and it's slightly faster
and lighter than its non-unique counterpart. Unique indices are not a required feature, they are an
optimization only.

Unique constraints are generally equated with candidate keys in a database. A candidate key is a
set of fields that, together, uniquely identify a row in the table. You can theoretically have
several candidate keys per table, though in Firebird you will identify them only as unique
constraints (it's a question of terminology at this point.) Foreign keys could, in theory, "point"
to any candidate key. A primary key is chosen among candidate keys for simplicity only; it is not a
required feature either.

You could, for example, have the following:

People (social_security_number, EIN, ...)
Address (social_security_number, street, city, state, zip, ...)
Phone (EIN, phone_number, ...)

Both social_security_number and EIN could, individually, identify a row. Both could be candidate
keys (two candidate keys, one field each). Other tables could have foreign keys using either one,
as they would be equally valid. However, it's much simpler from a maintenance point of view to pick
one of the two. The one you pick will be designated "primary key" and other tables are expected to
only have foreign keys to it. Makes diagrams easier, confuses fellow engineers less, etc.

Does that separate out the issues sufficiently?

-Philip