You'll have to emulate whatever Liferay does in order to create the whole portlet context. IMHO it's not worth it for the scenario that you're giving. What's the problem of adding your servlet code to a portlet, where you have all of this context?
You can't really deploy a servlet "into Liferay" - your servlet might be running on the same application server as Liferay, but when you look at the HttpServletRequest's targets, you'll see that a servlet request is targetted to your servlet's web application, which is deliberately separated from Liferay - a totally different and unrelated application. When you look at a portlet request, it's directed to Liferay and then internally forwarded to your portlet in another web application. All this is well implemented already and IMHO not worth pursuing. The appserver will resist giving you all the data from another webapplication.
There are other solutions, but they all seem to be prohibitively complex compared to moving the servlet code into a portlet, that I'd wait for more arguments why you definitely need to keep with this implementation before I mention them.