You're kind of thinking about it the wrong way, but I'll try to explain.
When you purchase bandwidth from an ISP, this is called transit (colloquially in the industry). Assuming you've got yourself some PI space (1.0.0.0/8, for example), you're paying your ISP to get your bits from your network to other networks. So say your AS is 6500, and your ISP is 3356. Bits from any other ASN will also need to transit AS3356 to get to you. Let's say that there's another ASN (6501) that buys transit from a different ASN (7224). AS3356 and AS7224 are peers. Now, in order for bits to get from AS6501 to AS6500, the path goes like this:
AS6501 -> AS7224 -> AS3356 -> AS6500
Now if you set up peering (also a colloquial industry term**) with AS6501, this eliminates the need to get bits from you to AS6501 via transit and vice versa, thus reducing your cost, AS6501's operator's cost, and also usually results in reduced loss/latency between your networks. Everybody wins! Now the path looks like this:
AS6501 -> AS6500
Your original scenario wouldn't work in the real world, because the assumption for AS6501 would be for it to incur a cost to get your bits across it to you from the ISP(s). AS6501 wouldn't be getting benefit by hauling your bits across it to your ISP so you don't have to pay your ISP. What's more likely is AS6501 would charge you to do this, at which point, you might as well just pay your ISP(s) anyway.
** The term peering is overloaded. It can be both used to describe a BGP session (e or i variety), as well as the colloquial/political sense, which means you and another network connect to one another and directly exchange traffic (via BGP) for mutual benefit - think opposite of transit. If you're running BGP with your ISP (transit), you're still technically peering with your ISP, because it's an eBGP peering. To help avoid confusion, it's better to use peering to refer to the act of exchanging traffic with another network at no cost (note that this isn't always the case) and BGP session to refer to the actual technical term for exchanging prefixes via BGP (iBGP or eBGP) with another router, whether a cost is involved or not.
This won't work the way you describe it. Each connection has its own public IP belonging to your ISPs. You'll need public IP space (typically called PI space - provider indepentent) which you can advertise via BGP to both your ISP's at the same time.
The setup you describes doesn't have a shared public address between the two connections and your ISPs won't route eachothers addresses, so what you're describing is a server which is reachable through two networks on two different IP addresses. NAT rules can't solve this for you.
Best Answer
You should run BGP on your Cisco routers connecting to ISP. If FW supports BGP, it should run iBGP with the routers.
I would prefer doing NAT on the FW. All you have to do is make sure that the traffic leaving a FW comes back to the same. I think you would already be doing that.
HTH.