Abstracting the ownership behind an interface presumably is needed when the ownership model is very complex. From my experience this is nothing but a big red flag. If you need a class to manage an ownership, it means that you can't easily trace its movement, in which case it means that it is a total bitch to debug, leave alone being able to read through the code and understand where that damn ownership is at any given moment.

I know it's beautiful language with a laundry list of features, but keeping things simple is still the best approach:

  #define __no_copying(type)                      \
                                                  \
	private:                                  \
		type(const type &);               \
		type & operator = (const type &); \
	public:

  class foo
  {
  public:
        foo();
        __no_copying(foo);
  ...
  }

In a spaghetti-less code this typically applies in 99% of all cases. There's a remaining 1%, which it's easier and cleaner to handle on a case by case basis.