It will take some work...
There are two issues to be worked around when considering a STL vs. a native OpenVSP prop.
1) OpenVSP knows where the kutta condition is. When you do a panel code analysis, OpenVSP knows where to apply the kutta condition (from how the model was constructed). That information gets written to the *.vspgeom file.
2) OpenVSP knows that you are writing out a propeller and it sets up the groups and other files appropriately.
For a STL mesh, you will want to tell OpenVSP to 'Use Alternate File format' on the 'Advanced' tab. This will tell OpenVSP to send the geometry to VSPAERO in a *.tri file (not the *.vspgeom). The *.tri file contains no wake information -- which will cause VSPAERO to search for the wake line itself. As long as your propeller is set up for forward flight, this will likely work OK (it will search for aft-facing sharp angles). If your propeller is set up for hover, it will likely attach the wakes wrong.
I would set up a generic (native OpenVSP) propeller in one directly and set it up to run a case.
I would then set up your case in a parallel directory and set it up as best you can -- but the rotation won't initially work right.
I would then compare the two sets of input files in the directories. In particular the *.vspaero and *.groups files. Hopefully you'll be able to sort out how to change the files to make your STL file rotate.
You will need to run VSPAERO from the command line. If you run it from OpenVSP, then scroll to the top line of the VSPAERO output console, you will find the command line used to execute VSPAERO that time. Copy that as a starting point for when you start working from the command line.
Rob