This subtle example of autovivification deserves a bit of discussion. It is not something that is self-evident in the docs.

First: autovivification occurs when an lvalue (cling to this word in the paragraphs below) contains references that did not previously exist. So this:

my $href;
$href->{smith}{john}{eyecolor} = 'blue';
[download]

works because the reference keys are autovivified to provide a slot for the value 'blue'. So far, so good...

But interestingly, even though it does not appear to be an lvalue, the following also causes keys to magically appear:

my $href;
my $color = $href->{smith}{john}{eyecolor};
[download]

In the process of looking for a value to return, Perl creates (autovivifies) the 'smith' and 'john', keys and then returns undef (eyecolor) to be assigned to $color. The Camel book (3rd Edition, p. 710) describes this while suggesting that this behavior may be "fixed in a future release".

The same goes for:

my $href;
if (exists $href->{smith}{john}{eyecolor}) {
   # do something
}
[download]

lvalue? bug? You be the judge.

So... to get closer to your code, if we said:

my $aref = undef;
my $a = $$aref[0];
[download]

We would not thereby create a zero-th element but we would cause the undef $aref to autovivify as a reference to an anonymous array in the process of looking for the non-existent zero-th element.

If you have made it this far, it's only one more step into the fog to suggest that (just as with the previous example):

my $aref = undef;
my @a = map {$_} @$aref;
[download]

is going to look for a possible $$aref[0] ...and in the process autovivify the $aref as an actual reference to an anonymous array (containing no elements).

Ain't Perl great?
HTH