I think you need to approach this solution in a sprint fashion.
You want to compare the time spent creating automated tests to running them manually. We'll assume you know the cost of doing your manual regression tests or this whole exercise is moot. The key is how effective your team is at creating and maintaining automated regression tests. If you have no experience in this area, this project may not be the time to start learning because you're not going to be very efficient and probably are unable to estimate the amount of time they will take. Still, you can try automating one or two of your tests and see how much time savings you can get along with being able to estimate the time to automate the rest (automation doesn't have to be all or none. Some tests may be easier to just do manually).
Do you know how many sprints are left? Very difficult to do an ROI on comparing savings on two approaches to a repeated task when you don't know how many times you'll repeat it. Maybe you are fairly confident you can come close, but if you feel there may be more sprints involved in this project than you think, even the slightest amount of time savings with automated tests may be a morale booster. If team members find themselves hating doing the tests and would rather tweak pixels in the GUI, automation may save your sanity.
History of projects with and without any integration testing. Did your team choose to do testing because they dreaded the projects that didn't have it or are you just following the fashion trends? This can be another sanity check. It also is dependent on the number of sprints left. Having a lot of sprints left may not be a sign of "just think how much time we'd save by not doing any regression tests" but "there are a lot of sprints left because this is a very complicated project, so having tests may be more beneficial than we think".
I don't think there is a universal answer for any team to test or not to test and how much should you automate them. Experience has a lot to do with it. Some projects are more conducive to implementing new things more than others. If the though of automating tests is going to throw your team in a panic that this will put the project too far behind, don't do it. On the other hand if they feel like they'd rather spend their weekend writing automated tests if it means they no longer have to keep doing it manually (Isn't this why we wanted to learn how to program?), that may be the route to go. What's the price of a happy team?