Your question is:
How do I prevent scrum from turning great developers into average developers?
Let's answer that. You list a number of problems that your team is seeing, and while they are not the fault of Scrum they are problems that Scrum is unfortunately prone to. Fortunately none of them are unsolvable within the Scrum framework, given the goodwill of the team and competent management.
Most of these answers require some level of influence. An individual developer in the team is not going to fix them on their own, but that is true of most team problems.
Everyone just wants to take something easy off the board that you can get done in a day so you have something to report in tomorrows daily scrum.
There are two problems here. Somehow the team has got it into their heads that a standup meeting is there so that those outside the team can check on their progress daily. That is not the point of a standup. Standup is for communication within the team.
To fix this establish it as the norm that the standup simply says what you are doing. It is perfectly OK to give a standup report that says "I'm working on the export to PDF feature, and I expect to continue that tomorrow." If the task is expected to take a few days, that it's absolutely fine if that is the report for all of those days. It's also OK to say "I'm designing the export to PDF feature. I should be done with that tommorow and I'll start coding."
It's also very important not to focus on how many stores each individual person completed. The focus should be on whether the team completed its commitments as a team. The scrummaster should emphasize this, and avoid any discussion or measurement of how many stories each person moved.
The second problem is caused by the first, which is the picking up of low handing fruit. It's a natural thing to happen if everyone's goal is to look good at standup rather than complete good work. But it should be addressed. Firstly, you can prioritize the tasks within the sprint, and you should prioritize the big tasks highest, so someone should pick up the big difficult tasks on day 1. In any case, if by day 2 of the sprint nobody has picked up the big complex task, then the scrummaster should say "I see nobody has started the database compression task - that's a big task and it needs to be started right away if we are going to finish it this sprint". If nobody offers choose your best developer and say "Cecil, can you pick that one up please." Don't forget to congratulate Cecil at the end of the sprint for doing a good job.
If the big difficult task is not taken early, and so doesn't get completed, then the scrummaster needs to address this at the retrospective and say "We didn't finish the database compression task, and that was because it was picked up too late. We need to pick up big tasks first." The team is responsible for finding a way to make this work.
I think if you have hard problems to solve you solve them by giving them to smart people then leaving them alone. You don't constantly harass them everyday demanding to know what they did yesterday and what they plan to do today.
Very true. But if management wants to do this they will, whether or not Scrum is being used. Take this issue to management. It's possible they may have the wrong idea about Scrum, or they may think that daily harassment actually makes people work better (I don't, but I've met managers who do). In any case, Scrum is no more than a contributory factor to this problem. If someone has the authority, exclude those outside the team - including managers, from the standup. Scrum rules say that only team members get to speak at standup.
Sometimes I will want to just be alone and think about a solution for a few days.
That's fine to an extent, and you should (as above) be free to report that you are "still thinking about a problem": however a few days is a long time in a 2 week sprint. It is possible to overthink a problem, and Agile methods in general are designed to prevent that. If you thought the problem needed a few days of design that you should have called for a design spike before starting it. If you think it needs more consideration that was anticipated, say so up front.
One thing you didn't say but I suspect is relevant: it's the responsibility of the development team to keep the code quality up. If the developers are doing a slapdash job, find ways to make them do a better one - but remember that Scrum is at most a contributary factor here. Lazy developers (or developers who think they are under pressure) will do a crappy job in any development methodology.
Finally
it's not that [managers] don't trust [developers], it's that they don't get things done without constant supervision.
I take that sentence to mean that you think your developers genuinely need constant supervision in order to do good work. If this is true of your development team, then guess what - you don't have great developers. You have a bunch of average developers, and I sincerely doubt that Scrum is having much of a negative impact on them. They would be doing the same thing if they were doing Waterfall, or Kanban, or unstructured cowboy programming.