There is a fine line between tackling a project that stretches you and one which can't be completed within reasonable time and effort. Engineers ought to be able to distinguish[1]. N.B. it is not for me to define "stretches you", "completed", "reasonable time", "reasonable effort". That's your decision 
However, there is also nothing wrong with trying something, finding where the pain points are, finding workarounds - and knowing what you would do better next time. Indeed, in some circumstances that can be positively beneficial, e.g. during job interviews being able to demonstrate that you are interested in the subject and in continuously improving your knowledge and judgement. Back in the 70s I built a 6800 computer (similar to an Altair 8080) from scratch. In many ways it was appalling, but I learned a hell of a lot and could discuss things with other people.
I would suggest that learning when and how to use (or to avoid using) FPGAs is a useful skill, just as learning how to programme microcontrollers is useful. I would also suggest that if you are starting from scratch, then the magnitude of learning FPGAs is similar to that of learning MCUs.
Have fun! 
[1] Eric Laithwaite at Imperial College used to set exams where one question was easy and sufficient get you a pass mark, one was more challenging and couuld get you a good degree, and one could not be answered adequately in the time available. He expected his undergraduate engineers to be able to determine which questions to avoid. If they couldn't, they wouldn't make good engineers anyway.
I have to say I'm studying physics, not engineering. We are somewhat supposed to venture even in stuff that cannot be explored in any reasonable stretch of time 
"The art of research [is] the art of making difficult problems soluble by devising means of getting at them."
https://www.azquotes.com/quote/777283"No scientist is admired for failing in the attempt to solve problems that lie beyond his competence. ... Good scientists study the most important problems they think they can solve. It is, after all, their professional business to solve problems, not merely to grapple with them."
https://www.azquotes.com/quote/905059But yours are good advices nonetheless!
One step forward would be establishing if it's absolutely necessary to use a FPGA.
I'm sure it'd be interesting to learn FPGAs per se, but nevertheless I need to know if one can make a functional scope with just a computer, a front end, and an ADC.
You need to capture samples at a regular defined rate without missing samples. Ideally you also do a little real-time processing to identify when to start/stop capturing them, i.e. a trigger.
Whether or not you need an FPGA depends on the sample rate and sample depth, and the degree to which you can/cannot rely on a computer to keep up. The latter depends on what other things the computer is doing and the guarantees about the computer instruction timing. I know of only one computer that guarantees instruction timing: the XMOS xCORE family. With all others you have to guess and test and hope that you have spotted the worst case. The guesswork and testing can be minimised by careful use of peripherals and by having the computer sitting around doing "nothing important". That is sufficient for many purposes.
Where a computer cannot guarantee to keep up with the input samples all the time, you have two choices: reduce the sample rate until it can keep up, or have buffers to match the peak/mean processing rates to the fixed input rate.
An FPGA has two things a computer (xCORE excepted) cannot have: guaranteed timing/latency and many independent operations occurring in parallel. The penalty is that the conceptual design and implementation technologies are completely different.