What you are maybe missing is a clearly prioritized backlog and proper WIP limits (work in progress limits).
First, assuming you are starting out using 3 states (Open/Backlog, In Progress, Done) the team needs to have a way of pulling items from the backlog according to the priorities set out by the product owner. It does not matter whether or not these are leftovers from the pre-agile time. Everything has to be prioritized against everything else, right? So assemble your backlog, giving the team the possibility to choose from the top of the backlog. It also does not matter whether or not the items are rough sketched bug descriptions or fully blown stories, what matters is that you have some kind of visualized representation of the idea of the product owner that the team can work with it. Transition to a more formalized way of defining these wishes on the way (until you end up with only proper bugs and stories in the end). Bugs are a fact of life in software development, so just treat them as stories when prioritizing.
Second, tell the team to come up with a maximum number of items that they would like to have in progress at the same time and let the team define this as their initial WIP limit. This value can be adjusted over time depending on the way it works out for you.
It also seems as if you think you know best how the team should organize their work (assign one new developer on bugs, keep others focused). I have seen this kind of behavior before and usually it is a sign of dysfunctional behavior. The team should know best how they solve the items on the Kanban board, provided they act and think as a team. This way they can maximize the throughput and utilize everyone to the best of his/her abilities. Interference from outside (micro-management and alike) can hurt the team. This said, there is always two sides of the story, as teams must grow and might need proper guidance to achieve a certain quality where agile practices work effectively. If they have problems splitting up the work this is something that can be addressed as part of retrospectives/feedback loops that are essential to improve things like the distribution of work for example.
Remember that Kanban is based on letting the team pull rather than pushing items onto the team. Finally, should you fail with the one big team approach, you and your team can always consider splitting up the team into several smaller teams, each having own Kanban processes and workflows with individual boards, tailored to the specific team's needs (e.g. a bugfixing team, feature team, tester team). In the end, you and your development team must govern the process, not the other way round.