I can see the root of your problem in this one sentence:
It seems to be a stretch to think that I can get them to dump Scrum for another project management tool
This is the root of your problem. You have no idea what Scrum is. It's not a "tool", and it's not "project management". It's a workflow concept. There is no application called "Scrum" which your project managers use to schedule features, it doesn't exist (or if it does exist, it ought not to exist because such a thing is stupid).
OK, so based on that, here's some other things you don't understand about Scrum, although I prefer to use the term "Agile" ("Scrum" is one small part of "Agile", and if you're doing Scrum but not Agile, you're probably going to have a bad time, which it seems you are):
Reduce meetings. Check-ins should happen once per day, if that. As an example of what happens (and probably is happening at your company): Let's say your developers work 8 hour days, 9am-5pm. Take out an hour for lunch, so 7 hours. Take out 30 mins twice a day for 2 daily check-ins, that's 6 hours. Take out about an additional 30 mins per day for walking to and from the meeting room, and context switching back and forth from "work-mode" to "meeting-mode, plus time waiting for everyone to sit and be ready for the meeting, and all the other nonsense that goes along, that's 5.5 hours. Take out an additional 15 mins per day, because nobody wants to be in the middle of a line of code when a meeting is called, so probably your developers are checkpointing their work and then sitting at their desk doing nothing for around 5 minutes while they wait for the meeting, that's 5.25 hours. You've cut off 3/8ths of your developers' 8 hour day, just like that.
Now, here's the alternative plan: Let's say you do a daily check-in ("standup") once per day, and let's say you do it at the very beginning or very end of the day (beginning is more useful, for a reason I'll get to in a moment). Now, you've saved 30 mins of meeting time, plus 15 associated minutes of context switching time, plus 7 mins of waiting time, that's almost an hour. That's almost an additional hour per day that your people can be doing things. It's about an extra day per pay period (assuming your company has biweekly pay periods). Would you rather them be using that extra day per pay period to do work, or to sit in meetings? It's up to you.
As for why you should do standup in the mornings: Standup is primarily for planning the day's work ahead. The previous day's work should be briefly mentioned, because you want to know what people have gotten done, but if you have a functional Kanban Board you shouldn't need too much detail on that, it should be evident from the board status. So the main point of standup is to plan today's work, and to share any issues that people are having from completing the previous day's work ("I planned to do X yesterday, but I wasn't able to because of Y"). Then you can spend the first part of the day with people giving help to those who have problems to help them resolve their problems. That's called being "Agile": You don't just focus on your work alone, instead you help everyone to get everyone's work done as efficiently as possible, moving from place to place, task to task, sometimes helping others with their tasks instead of just your own, and responding in an agile way; that's specifically why it's called "Agile" and not "Scrum", as mentioned above.
As for velocity: It sounds like your developers are being overloaded and they don't have time to complete the features they are assigned. There is an old saying: "Do it right, or do it twice". Sure, your developers can pound out code and get something delivered, but if they're just pounding out code to meet some deadline, the code they pound out is not going to be high quality, and you're going to have big problems (I was laid off from a company that did this, where the company had this sort of philosophy, and because of it they hemmhorraged money and laid off over 50% of their dev team, myself included). In the end, they didn't do it right, so they literally had to do it twice (actually I think they did it 3 or 4 times). This is why project deadlines should never be decided by project management or sales teams alone: They are not technical people and they have no idea how long it takes to get things done. They can say to a client "We'll build Google for you tomorrow, complete with GMail and Google Photos and Google Hangouts, and the best search engine on the planet, we'll build it for you and it will be done tomorrow". But when you actually try to do it, it turns out you can't build Google overnight, and even Google did not build Google overnight. This is why most functional companies have some input from development teams when it comes to getting things done, either during negotiation with clients, or they get some go-ahead from the client to reduce feature requests pending developer availability. Without either of those things, everyone in the work pipeline is blind: The developers are being told to do something way above capacity and they can't talk back, so they just do it and it turns out to be crappy. Project management has no idea that the work is crappy, they just take what the devs provide, and they won't know how bad it is until it's done. Sales has no idea what it takes to get the job done right, so they overpromise and underdeliver in order to get contracts, and the end-client thinks they're getting the world but actually they're going to end up with unusable garbage and they're going to badmouth your company. Nobody wins.
As for how to solve this: Your developers need to have input into how big the feature requests are. They need to have the ability to go to project management and say "You are asking for a week's work to be done in a day, we can't do that, you need to reduce your ask so that we can do it properly", and project management listens to them and helps them, rather than pushing a timeline from Sales. It's on you as the team lead to be the one to have that conversation with project management on your team's behalf: You are their shield to protect them from unreasonable requests that can't be completed, and to manage expectations for what's coming out of your team in terms of features. Additionally, you should have sprint planning meetings to prioritize and allocate tasks, and make sure your developers aren't being overloaded by being assigned too much work for too short a time (this is part of Agile, which is not part of Scrum, which is why it's important to do Agile and not just Scrum, and why Scrum doesn't work without Agile)
In summary, here's what you can do to help your team:
Reduce meetings and cut down daily check-in to once per day, in the morning. It doesn't matter that this is "company culture" or whatever. You lead your team; if you can't even do something as small as determine how many meetings your team has scheduled and when, you're not a leader except in title.
Push back against unreasonable requests from Project Management to ensure your team has the time allocated to complete their tasks. Shield your team from things that you know would be unreasonable to ask of them, and make sure that the work your team does do comes out right.
Do sprint planning to make sure that you are allocating your resources effectively. Do not plan for 100% capacity of work for each developer, you're not going to get 100% capacity; you may get 80% capacity if you're lucky, you're more likely to get 70-75% capacity, especially from a team of junior developers. It sounds like right now you're asking for 120% capacity, and that's why your work is coming out like garbage.
Remember: Do it right, or do it twice.
