The iteration-is-not-a-unit-of-work antipattern

This is an antipattern that I've seen a few times in teams that are making the transition to XP or agile development. It manifests itself when organisations that are used to thinking about fixed time and scope projects draw up a release plan, typically the plan for the first release. The stories are discussed and prioritised and allocated to iterations as usual, but from that moment on the plan is treated as if it were fixed, and as if the delivery of specific stories at the end of specific iterations was guaranteed.
But of course it does nothing of the sort. The iterations in a release plan are not units of work ("these stories") but units of time ("this many days"). Trying to make an iteration into a unit of work requires that either its length varies to reflect actual effort required, or that the team is put under constant pressure to squeeze varying amounts of effort into some arbitrary time span. In the first case it's hard to track work completion properly and commitment to a release date becomes impossible; in the second case quality and morale slips and the team (including the customer) loses the ability to steer the project in a way that accomodates change.
Reflection: have you seen this antipattern? What was the outcome? What lies behind the desire for a release plan to be fixed or guaranteed? Are the other ways of dealing with these forces that would not cause an iteration to be treated as a unit of work?