Writing unit tests is not difficult - as the saying goes, it is matter of simple programming :-) So if you are competent programmer, and are willing to learn necessary skills and patterns, you can do it as QA engineer.
But IMHO (and best practices say that) developers are much better suited to write unit test - because unit tests use internal calls to application objects and methods - exactly the same calls developers already know how to use for application to work. So developers already should know how application works and what is expected correct result (change of internal status, which might or might not have equivalent in UI) of any internal method/procedure call, and can write unit-test for it without too much additional effort. If QA writes unit tests, s/he needs to learn all that.
Also, writing code which is easy to unit-test is good practice - developers should be doing it, because it forces them to write better code (code which is easier to test is also easier to understand and maintain). Ideally, in test-driven development, unit-test are written before code.
One reason why unit-test are good practice is that unit tests detect error closer to source where it occurred - unlike system-level test, which often detect error after it significantly confused system, and it may take complicated detective work to find core cause of a detected problem (which code unit is causing it).
You can learn these internal APIs and write unit test too, but with selenium, you test application from the "outside": which user actions will have which visible results.
You are right to be afraid to get pigeon-holed in single role. Learn as much as you can from adjacent areas - but decide what are your core skills, and put focus on those. I read somewhere that skills needs to be T-shaped: covering wide area even if shallow (not very deep), and deep in part of that area (your core expertise).
Nobody can give you guaranteed answer to your second question, only yourself can. Consider for current skills, your interests, company needs, paths to advance your career in your current company and other companies in your area, overall market, and possibly other markets it you want or are willing to relocate.
If you want to become developer, and your company is willing to get you training or even pay for it, writing unit tests for existing code might be a good way to transfer from QA to development. It will force you to learn how internal methods in core of your system work, and writing test is safe way to learn system because your code cannot break existing functionality. Bug in your test will be false positive (which is easy to detect and fix), or worse, false negative - test not failing when it should. But bug in test has no effect on user-facing functionality.
But if your company thinks that QA testers should write unit tests (and you cannot argue otherwise, even if best practices say it is better done by developers), maybe you need to look for an opportunity to work for a saner company (where you can improve your core QA skills more effectively).
Also, if developers in your company do not write and use unit-tests, they likely ignore other best practices, and you will improve your skills faster in different company (so you may consider looking for opportunity to work for a smarter company). Or you may try to explain your developers why unit-tests are good for developers too and THEY should write them (because it will help THEM to write better code, which is safer to refactor and improve).