We all started somewhere and frankly, if this drives some people to better contribute to themselves and the world or even just find the niche in life they've always wanted to be in, we'll have seen an excellent consequence.
A year of independent course work is unlikely to be enough to teach the automata theory/set theory/discrete mathematics/et cetera (ad infinitum) that is vital to developing a core understand of what one is interacting with in professional coding much less the various other "softer" disciplines required to know how to write code of a high level of quality. That said, even with many years of university, employment, and success behind me I am continuously learning, expanding, and refining myself. The risk, of course, is that low quality coders could result.
To counter-balance again, I generally like working on the harder and more interesting problems and this means that team members who are intimidated by those and as a result are happier with their job when doing the work that I do mostly because it needs to get done can be a godsend to my own happiness at work. Developing a mentoring relationship with such individuals has additionally been really gratifying.
ITIL, as mentioned previously does a good job of discussing IT from the perspective of the people that make decisions such as the creation of a new department and how they would prefer to interact with such a department. That said, it is rational only at a large scale where such abstractions are necessary to manage people in the absence of more personal relationships. As such, it can provide you with an understanding that will help you communicate with the decision makers about how your suggested organizational change will serve their purposes.
The following will likely be relatively unintelligible to the powers that be but the reason for rationalizing (or not) the separation of IT into a distinct organizational structure is the separation of concerns (suggested reading). More specifically: the concerns of an IT department are very different than the concerns of an engineering department. In order to better define and understand the IT needs of the organization, a separate organization will serve the purpose of better meeting those needs. Of course the risk of this is that either of the engineering or IT organizations will become blind to the concerns of the other through organizational dysfunction in the form of an "us vs. them" mentality (clearly given some of the comments here, this isn't unreasonable to expect [as you've noted]) or reduced communication and collaboration. Therefore, if such a division is to occur, it will be important to those approving of it that strategies are in place to address such possibilities: that the change will bring greater value to the organization as a whole over the alternative. If the concepts and changes are rolled out properly, the engineers will be glad not to have to deal with the day to day tasks of IT operations as it will free them up to remain more focused on their own concerns and IT can be glad to have independence to do their job well and grow in their ability to do so as well as to gain a distinct voice in the discussion of how to support value creation in the organization.
In such considerations, the size of the organization is key. In small organizations, the greater efficiency of having single individuals playing multiple roles requires the fusion of roles. As organizations grow, the separation of responsibilities that allows those responsibilities to be performed with greater skill, sophistication, and complexity begins to outweigh that initial efficiency. You will have to answer for yourself where your organization falls on the spectrum of size and what the trade offs of separation look like or else you will be unprepared to answer the questions and concerns of your management.
Based on your communication, it would seem that you have already identified some key consequences of the lack of separation and those will serve as good pieces of the rationale you can present. It would also seem that you have established a reasonable amount of trust and authority for yourself with the organization. It will be important that you remember that the things which seem obvious to you are clear in your mind because you think about and deal with them on a regular basis. The people you'll be talking with do not think about or deal with those things and they like it that way. You will be asking them to think about these things that they don't want to think about so it will be key that they feel you've thought through the change to maintain the trust you've built as well as supporting further trust that you are trying to better serve the needs of the organization. Part of that should include being up front about your own desires to head the new department but you'll likely not want to emphasize that too much - the fact that you're developing these ideas and considering these concerns presents you as the natural choice for the position so it will be yours to lose if they buy in to the change.
Best of luck in creating your new position and department as well as supporting your organization's success.
"Free markets select for winning solutions." -- Eric S. Raymond