Firstly, this sounds fantastic, not least of which is the research into the original Arkanoid game. I have a version of it on my son’s XBox and it’s about right but has a few minor differences. It does however have the aliens that you mention.
Putting the technical stuff to one side for a moment, when the ball hits the aliens it also rebounds, something to consider - this is their main point of being in the game, as they dont actually cause any damage to the player (the bat) - at least not in the XBox version anyway. The aliens also bounce off of the blocks, slowly manoeuvring their way downwards. One of the alien types on the XBox version (a set of what look to be 3 or 4 orbs stuck together) actually cause damage to blocks when they take their first hit to separate them.
They can also be shot if you have laser.
Now… regarding you post in more detail… 
Stop adding awesome new features all the time then! 
Of course, where’s the fun in that… but I understand your desire to move on through the course. If you don’t implement these features yet, just be sure to have a clean working copy of your game at this time and keep a really good log of the features (and any potential defects) before you move on - this will make it a lot easier when you return to it later 
I don’t recall exactly where Ben refers to the MVP - Minimum Viable Product - but that would be a good way to approach this feature. You have outline what the original did and how it functioned and what it needs to do and woooaaah, so many things! So, what’s the least it could do to get it started?
- Do you need fancy sliding doors opening at the top of the level? (XBox version has a number of places on the side walls too for this)
- Do the aliens need to animate?
- Do the aliens need pathfinding to home in towards the player?
- Do the aliens need to cause damage to blocks?
- Do the aliens need to rebound the ball?
- Do the aliens need to create a particle effect when destroyed?
My point here is one of taking a feature and breaking it down into many smaller features. Then, start with the most simple of things to start the whole thing off.
Phase 1
- use a simple/basic/plain sprite
a simple shape would do, maybe a circle, in one colour
- spawn an alien
perhaps on a key press initially just so you can add some whilst play testing
- limit the number that can be spawned
perhaps have this as a configurable variable
- keep track of the number of spawn aliens
- keep the game running as it did before with all of the above new stuff implemented
Phase 2
- destroy an alien
again with a key press perhaps
- update the number of spawned aliens
You can now add and remove aliens on key presses in your game. Which, importantly, still works. Sure they don’t really do anything yet but you can start ticking off those smaller features which is hugely beneficial for a feel good
factor, and enables you to make iterative progress carefully, rather than jumping right in and worrying about screwing the whole project up 
The above are just examples, but are fairly small. You could also for example add the particle effects to Phase 2. Now you can add / remove aliens and it looks pretty (ish).
Gradually add each additional small feature to the bigger feature. As mentioned before, if you’re not using source control yet, do, you could create separate branches for functionality you want to test, like for example the pathfinding. If it all goes horribly wrong, no problem, just grab a copy of the source again pre-changes 
If you wanted to go a step further (as I would) you may want to list all of the smaller features and then score them. Scrum, if you are not familiar has a method for this which involves giving these features a value, such as “story points”, effectively a number which represents the challenge/effort required of the item. So, to just spawn an alien within the scene on a key press may perhaps represent a value of 1. This doesn’t mean 1 day, or 1 week, or 1 unit of development, but for you you know its something that now doesn’t represent a significant challenge.
Now, if you consider the pathfinding, if at the moment you don’t know anything / much about that (or which ever feature is the more daunting), if it’s something entirely new which may involve creating a separate little mini project to test a few things out and so on, that sounds quite a lot bigger, so maybe you score that 100. You are indicating that this is going to need some serious thought, work, and invariably perhaps duration.
Once you’ve scored all of the mini features you can then reflect on your list and decide which ones you can implement fairly easily and swiftly. It’s worth revisiting the scoring incidentally. Chances are as the days/weeks go by you will start to read up on various techniques for some of the other features and maybe what was a 100 previously becomes a 40 because you have found a really good tutorial that fits perfectly or you had that flash of inspiration in the bath - whatever the cause, re-evaluating the scores of the features can be beneficial so you don’t always assume that the 100 (maybe deemed worst) item is always last. Maybe you just set aside some additional time to tackle that bad boy for the next couple of weeks.
The development phases are typically referred to as sprints incidentally, but I left it as Phase 1 and Phase 2 at the top as I’d not mentioned Scrum at that point 
Sorry about the length of the post, but I just wanted to circle back to the MVP. Little successes frequently will be very rewarding and are much more likely to keep your motivation high and as such, make the harder tasks easier to resolve.
I hope this is of some use, if nothing else, maybe to make you tired for a good night’s sleep! 