Start with the attitude of "I want to give it the best try I can, what are some ideas/tips for making this successful?". Be very conscious of that as your approach and avoid any signs of despair, hopelessness or unwillingness to try. Everyone has some chance of failure, and if work is urgent, and resources are tight, some work is better than no work on a critical task.
I would set up a meeting with your manager, though, "kick off" for the work. It's a good idea even in a normal situation, but in a serious challenge, it's even more valuable. Things to cover:
What are my resources for learning?
You should already know the resources for everyday work - like helpful websites, internal coding standards, how to run the environment and any development tools, etc. This would cover things like:
- are there guidance documents for bigger projects? Design standards, processes for peer review, etc?
- is there someone on the team who's designed something like this before who could be a go-to guy to answer questions? How much can you tap his time (1-2 hours/week? 4-8?)
- is there something you can use as a reference? A previously written library that everyone likes? Some sort of sample to give you something to imitate?
What is absolutely most important to have this month?
Generally, the bigger the work, the more ambiguous it will be. Refining a project, honing in on the priorities and planning out big work to be acheiveable are the critical skills of just about any sort of a senior position. You aren't senior yet, so you probably will need help in this area. A really key element is to ask - no one can work by psychic interaction! Hopefully, your management is ready to provide some guidance here... but if not, be prepared with your break down of the work and a tentative thought on priorities. It is far easier to correct a list of priorities than to develop one from nothing.
Here's my method:
1 - Write down any discrete work that comes to mind. It might be specific features, it might be some underlying prep work that needs to happen first, it could be parts of the design phase. Chances are good that your to-do list items are a mix of all sorts of things that can't be compared.
2 - Connect any dependancies. Once you'll have a list, you'll find cases of "can't do X, Y or Z without step 1", "can't do A or B without X" and so on. That'll give you a place to start.
3 - Write a first priority list. I can guarantee that you won't have a clue on a big chunk of it. So take a guess. Generally, anything with a lot of dependancies needs to be high on the list, and it needs to come before anything that depends upon it. You may also order it with an eye to verifying completeness - no point in doing something if you have no way of knowing if it was done right.
4 - Book time with the boss and discuss it. I recommend for highly uncertain work that you push hard for a very ordered priority. Not High/Medium/Low and a "please get all Highs done by the end of the month" but an ordered list from #1 to #n.
5 - From there, try to give feedback on your own cut line (items higher than X will get done, don't have time for the others). Tell your manager what you think is reasonable and have a discussion from there. He's got a right to reprioritize, but not to tell you that you can do more work - particularly without offering additional resources (and I don't mean money!) that change your estimates. He can say - "why do you think that is hard... here's a way to make it easy" - and change YOUR opinion.
A libarary is an amphorous thing - just look at the public APIs out there - they grow and grow, with many different features. The ideal is to pare down that first attempt to a bare minimum that will get anyone waiting on it into a state where they can be productive. Anything that won't be used should be deferred.
How/when does the manager want status?
You don't want to ring the alarm on every issue - but how long should you spin your wheels before begging for help? What kind of status should you report? How often? In what format (email, meeting, etc)?
What are your factors for time vs. quality?
Chances are good that you could do a small chunk of the work pretty well, or a bigger chunk with more flaws and errors. As you finish prioritizing, try to get a sense of which is the bigger priority.
Usually in development, this has a lot to do with what phase you are in and who's going to have to use this thing next. For example:
Internal, nearby fellow developers - if the next thing is software integration testing, and the folks using your work are all nearby fellow developers, it will be pretty easy to resolve early issues with a quick yell, and an informal conversation - maybe you have to fix bugs quickly, but you can do it and return the fixes with minimal overhead and no political/reputational fall out for the company. In this case, minimal testing in favor of additional features may be the way to go.
Customer release - if this libary gets released to external groups or a customer, and will be billed as a solid product of your company, you are on the other extreme - one, very well tested, very well designed feature may be much better than every other capability.
Chances are, your project is a shade of grey... but do the best you can to clarify this. No manager wants to pick an absolute, but it's an important point - you can't do both in a limited time, and erring too far to the wrong extreme will mean a big gap between what you provide and what they expected, which works well for no one.
What do I have going for me?
Yes, this is asking for a pat on the back. But in a tight spot, it's good to know your strengths (and your weaknesses). From the post, it sounds like you already know your weaknesses, so it would be good to get a sense of your strengths. Sometimes they are hard to figure out, and you want to know any good things that you already do that you should keep up.