Regarding the ASNs, you have a lot of options. The least-complex choice is to treat ASN 65000 as a downstream private ASN customer of ASN 98765, accept Internet-bound routes from it, announce default (or DFZ, if you must) routes to it, and
remove-private the ASN 65000 from AS_PATHs when you export them to your transit.
At the other end of the complexity scale is confederating so 65000 is a sub-as of 98765. This might make the network topology easier to understand, and routing protocol a little easier to express, while avoiding some MPLS-related obstacles in case you wanted to transport labeled VPN or INET traffic across both ASNs. I personally would not do this unless your network scales up considerably.
vPC for border
I assume the alternative you are considering is to not use vPC for that pair of border routers, and instead, configure/manage them separately.
Separate border routers is my recommendation for the border role because two separately-managed routers generally have less chance to fail simultaneously due to bugs or software/hardware upgrade complications.
In the border role, you get fewer advantages from technologies like vPC/StackWise/etc since it's likely all the neighboring routers will be speaking routing protocols. The benefits of things like MLAG or StackWise+EtherChannel are not there. You're also not trying to deliver L2 while avoiding STP. You pay all the MTBF & MTTR penalties for vPC but don't get most of the advantages it comes with in other roles such as top-of-rack.
I hope this helps.