Your splitting constructors idea is odd. One rarely writes functions that modify arguments, much less a constructor that modifies another instance of the class. This smacks of std::auto_ptr!
I think a better approach is a static member function, split(), that would better parallel the join() member function. Thus, for parallel_reduce(), you'd write:
Example(/* appropriate parameters */);
join(Example const &);
operator ()(tbb::blocked_range const &);
This makes split() a factory function, of sorts. It is still a function that modifies its argument, but at least it isn't a constructor and the name clearly parallels that of join().
I'm sure you're concerned about backward compatiblity. You should be able to use template metaprogramming to determine whether the object given to parallel_reduce() is of a type that provides a static member function named split() or a splitting constructor while deprecating the latter.