To address the first problem, you should offer a passive solution and not require the user to set up anything special in the way of single-use URLs. In fact, I assumed the issue of payers sharing the end-link was such an obvious problem that the service would have already addressed this and had it built-in by default (but of course, MVP/first-release, I understand).
The way I'd see it working is, I give Gumroad a link I want users to pay for, and Gumroad charges each user, serving up the content, but never sharing with them the link that I gave Gumroad. You could do this by fetching the content on the back end, and serving it up through Gumroad's own single-use URL.
Sure, that would make sense for content that could be so served (for example, the pencil icon used as the example here) - but not all content is like that. What about content you want people to interact with (a blog post on your site, a special beta registration form)? You also take on all the problems of becoming a content distributor rather than a link distributor.
I agree with everything you said. If this were my project, these are all problems I'd be thinking about and trying to address. Looks like you're on the right path ;-)
and I would add that the content distributor problem is also a good one to solve (with your solution). May even be more profitable... a lot of people want to sell stuff, not link.
The way I'd see it working is, I give Gumroad a link I want users to pay for, and Gumroad charges each user, serving up the content, but never sharing with them the link that I gave Gumroad. You could do this by fetching the content on the back end, and serving it up through Gumroad's own single-use URL.