I'm afraid I have to disagree: By design, Spring supports circular references for singleton beans only. That's simply a known limitation.
We deliberately chose to not support circular references for scoped beans when we introduced them back in Spring 2.0. Personally, if I got to choose again, I would stick with this decision and not even support circular references for singletons beans either. Circular references introduce more problems that they solve, even for singletons. Some party always gets a not-quite-fully initialized reference there. Anyway, let's leave the well-known circular reference discussion aside and focus on potential solutions...
The underlying reason for the limitation with scoped beans is the Scope SPI. The get operation accepts an ObjectFactory and provides atomicity guarantees, i.e. it never returns a half-initialized object. The scope backend may even build those objects on remote servers or the like, returning a serialized form of it, or it may return a proxy to a cluster-wide shared object. (Custom scopes are used for those kinds of things as well, e.g. with Terracotta as a backend.) In such a scoping scenario, circular dependencies are a no-go to begin with.
So what can we do about it? We could define a new optional operation for Scope implementations, exposing a reference while the object is still being initialized. That's not quite trivial in the details for several reasons (such as doing it on demand only, as well as dealing with clustering side effects of premature HttpSession.setAttribute calls) but doable in principle, at least for request and session scope. We're going to revisit this for Spring 3.1, next to conversation management which happens to be a related topic anyway.