Velocity is very useful for estimating schedules or generating planning values, and can also be a meaningful detective control for assessing process bottlenecks or changes in team capacity. It is not, however, a valid measure of productivity.
When Velocity is Confused with Management Targets
"Velocity" is a range that expresses a team's average capacity over some historical period. It is a statistical analysis of past performance, which can then be used to project probabilistic estimates of future workload capacity or cycle times. This is in stark contrast to a "scheduling target," which is a managerial objective that sets a timeline or goal for planning purposes.
Experienced agile project managers know that the proper use of velocity is to determine whether a team has the sustainable capacity to meeting management-defined scheduling targets. Sometimes the answer is yes, and everyone is happy. Sometimes the answer is no, at which point the iron triangle forces business decisions about scope, cost, time, and quality.
Evaluate Your Political Options
We have an average velocity of 50 story points...I have been asked to increase it by 40% to 70 story points (with no increase in team members).
Assuming that your estimation practices are sound and that your velocity is reasonably stable, your manager will get no joy from adjusting the estimate scale or setting management targets not based on historical performance. As you correctly point out, this is fundamentally a capacity problem.
The capacity limit may be related to the number of people on your team, or it may be a limitation of your organizational processes. Of course, adding more people doesn't always add actual project capacity either; see Brooks' Law for more on this common misconception.
The problem you face is political. From the tone of your post, it sounds like your manager wants to see an increase in productivity without making any actual changes to the team's underlying capacity. The solutions are therefore also political, and largely educational in nature.
If you are a Scrum shop, ask your Scrum Master to address this issue through the appropriate framework channels. Backlog Grooming and Sprint Retrospectives are often the ideal inspect-and-adapt opportunities for this particular issue.
If you're not a Scrum shop, you must decide what the proper way to address your concerns are within your organization. If you're on good terms with your manager, you might even loan him a copy of Agile Estimating and Planning for the two of you to discuss over lunch.
If all else fails, prepare for a death march by brushing up your resume, and doing your professional best until the project implodes. 68% of IT projects fail; unless management targets are solidly grounded in organizational capacity, yours will probably be one of them.