If it fits within the rules of normalization, then 1:1 relationships can be normalized (by definition!) - In other words, there is nothing about 1:1 relationships that make it impossible for them to obey the normal forms.
To answer your question about the practicality of 1:1 relationships, there are times when this is a perfectly useful construct, such as when you have subtypes with distinct predicates (columns).
The reasons you would use 1:1 relationships depend on your point of view. DBAs tend to think of everything as being a performance decision. Data modelers and programmers tend to think of these decisions as being design or model oriented. In fact, there is a lot of overlap between these points of view. It depends on what your perspectives and priorities are. Here are some examples of motivations for 1:1 relationships:
You have some subset of columns that are very wide and you want to
segregate them physically in your storage for performance reasons.
You have some subset of columns that are not read or updated
frequently and you want to keep them apart from the frequently used
columns for performance reasons.
You have some columns that are optional in general but they are
mandatory when you know that the record is of a certain type.
You have some columns that logically belong together for a subtype
and you want to model them to fit well with your code's object model.
You have some columns that can only apply to some subtype(s) of an
entity super-type, and you want your schema to enforce the absence of
this data for other subtypes.
You have some columns that belong to an entity but you need to protect
these particular columns using more restrictive access rules (e.g. salary
on an employee table).
So you can see, sometimes the driver is performance, sometimes it is model purity, or just a desire to take full advantage of declarative schema rules.
