Dynamically instantiating classes
There's a lot of design oddities in this, and I don't quite see the value of it.  The brevity it allows now will undoubtedly cause issues once you use this in a complex application.

Why is:

$core = new Core();
$core-&gt;init('User, Control');

$core-&gt;Control-&gt;test2();

echo "&lt;br /&gt;";

$core-&gt;User-&gt;test();


Better than:

spl_autoload_register(...);

$control = new Control();
$control-&gt;test2();
$user = new User();
$user-&gt;test();


Autoloading is typically setup in some form of bootstrap.  It is usually done in the same place that DB connections are made, application-wide configuration is put into place, etc.

This mean that your main script content should never have to worry about autoloading since your bootstrapping will have already taken care of it.

(Note that a boostrap does not need to be a huge complex process.  Sometimes it can be as simple as include 'boostrap.php';)

Anyway, your class has a few design problems and a a few implementation problems:

Design:


What if you want more than 1 User object in the core?
What if you need to pass a parameter to a constructor
init() can make the state of the object unknown.

if you pass a Core instance to some other place of code, how does that code know what properties are valid on the object
This type of magic almost always ends badly since it hides state information



Implementation:


__get should check if the key exists in $extra before blindly accessing/returning
Unnecessary string processing: Why explode a string?  Just use an array.  It's cleaner and less error prone.
If you do keep this class (which I advise that you don't), I would consider making the init() part of the constructor.  I like to ensure that all of my instances are always in a stable, usable state.  What happens if you use a Core instance before calling init?
Setting up autoloading, storing objects and creating objects are three discrete responsibilities.  This means that the class is likely doing too much.

Once again, I recommend not using the class, but if you do:
Have the constructor take in an Autoloader instance and have that class handle loading
Have the class take in instances instead of names (this decouples creation from storing -- which is good since it means you have much more control of instantiation -- but it will kill the brevity of using your class)