This isn't something you're going to easily be able to "hack in" with a plugin or some small set of code.
The short of it is that SVGs, by and large, are not "images" in the sense of all the images that have came before it. SVGs are vector based images, and the first ones to get any real traction on the web.
All images before that have been bitmap based. WordPress's image handling system was written specifically to deal with those, and this inherent design is located at every point in the system.
It's an underlying assumption that images have widths and heights, for example. SVGs have neither, they can be any size. There's a whole basic "editor" for images built into WordPress, none of the functionality of which can really apply to SVGs.
The multimedia system is slowly being redeveloped, with the emphasis here on "slowly". There is a whole lot of backward compatibility to be maintained and new designs to be implemented. Additionally, most people are far more interested in supporting video, audio, and playlists. As this redesign work is done, and sections of the library become more abstracted, then this sort of thing will become easier to support over time. But it's not there yet, and it won't be for a while. This is why the SVG mime type isn't supported, because adding that mime type until all the underlying pieces work would be a road to breakage.
For SVGs, the wp_attachment_is_image should return false, because wp_attachment_is_image is used to determine whether or not to show the editor button and whether or not image_downsize tries to resize the image into the thumbnails and such. Neither of which would work for SVGs anyway. To properly support SVGs, you would need to write a new system for adding metadata for those images entirely, and then add support for it in all the places that metadata might be used. As you can imagine, that isn't a small job.