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.