You raise a few issues here.
The issue with returning a reference or pointer to a local variable is that the variable will pass out of scope when the function returns, so you have a reference to an object that formally no longer exists. If you use that reference, the result is formally undefined behaviour. The issue with returning a reference to an object created by operator new is that you will (eventually) need to obtain it's address to delete it or face the prospect of a memory leak. In other words, you gain nothing compared with returning a pointer.
There are a number of practical solutions in C++. Applicability depends on what you're doing. Options include;
1) Return a reference to a global object that is guaranteed to exist for as long as you need the reference.
2) [Applicable if the function returning a reference is a member function of some class]. Return a reference to a data member. In some circumstances, this violates encapsulation (by allowing unchecked modification of private data) but this is actually what is done in the stl (indirectly) using iterator types.
3) Return a reference to self (eg return *this
Often used in things like user-defined assignment operators.
4) Return data by value rather than by reference. The compiler guarantees that a copy of the object will exist until the next sequence point in the caller. This allows the caller to copy the data to somewhere it can use it. With a decent compiler and optimiser, the number of temporary objects created and deleted can be minimised (this is something specifically allowed by the C++ standard).
I'm sure there are other approaches that I haven't thought of in the last minute or two :-)
Most abstract factory methods (or objects) as implemented in C++ create objects dynamically (using operator new). They may return raw pointers (in which case the caller is responsible for avoiding leaks) or may return a smart pointer type (eg std::auto_ptr<Object>) that will manage object lifetime for you.