Perhaps it simply means that you should focus on being a UX researcher instead of a UX designer. There are generally fewer roles for researchers than designers, but there are still opportunities for those of us who love UX research, and who understand design but aren't designers.
Personally, I've been a UX researcher for 12 years. I'm definitely not a visual designer (I can barely draw a stick figure!), but I can research how visual design impacts the ability of a user to complete a workflow or their impression of a product. I'm not an interaction designer either, but I can research whether an interaction meets its goal, and I can do formative research that helps interaction designers decide where they should focus their design resources.
I think that having an appreciation for good design is necessary for being a research, but I don't think that having that same passion for creating the good design yourself is necessary. I am good enough with applications like Photoshop, Omnigraffle, and Balsalmiq to use them for my purposes as a researcher. I am a pro with email, calendar, PowerPoint/Keynote, and the other applications that are most important to me as a researcher.
I like UX research because I like challenges, and I like answering difficult questions. I like being able to work with designers and developers to figure out what they need to know. After all, just like users can't always articulate what they need to solve a problem (or can't always articulate that there's a problem at all), designers and developers can't always articulate what research they need to help them create a better design or better code (or can't always articulate that they have a a research need at all). I like working with designers and developers as the research is conducted, so that they can have a strong understanding of what is learned during the research and how to move forward with it. And I like working with designers and developers after the research is done so that we can together determine how to handle changes in schedule, changes in plans, changes in business goals, and all of the other changes that occur during the software engineering lifecycle.